Half of curl’s vulnerabilities are C mistakes | Hacker News Reader

Half of curl’s vulnerabilities are C mistakes

daniel.haxx.se

152 pointsdsr1237 comments

Are there good solutions for creating (pie) charts that aren't completely opaque to people with color vision deficiencies? This article is especially egregious because I feel like they actually add to the point being made, but for the life of me I can't distinguish some of these colours. Who uses yellow (or orange, idk) for four separate labels?

Perhaps related, does anyone know of an overlay-type application that allows me to colorpick part of the screen (on linux)? My current solution is usually to screenshot and open the image in the GIMP or similar, but it's very cumbersome and especially if there are multiple pictures usually not worth it.

The pie chart's legend in this post is sorted largest number to smallest number, if that helps. Or as table:

Buffer overread: 22 Buffer overflow: 20 Use After Free: 4 Double Free: 3 NULL mistake: 2

I don't know about any resources for accessible colour picking, but if you're looking for a colour picker to work around badly designed charts, there's Pick[1], which is easy to work with. It also displays you the closest colour name, so you don't need to manually parse hex codes to see the difference.

I'm not aware of any colour disabilities that I have but I found it difficult to parse the colours as well, specifically in the second pie chart (areas). The colours in the chart only work to distinguish one slice from its neighbours, it's near impossible to map them to the categories listed in the legend. Perhaps the author is working on a super-colour-accurate computer screen where this problem isn't as noticeable, but on my older screens these colour profiles are near useless.

If you're in Firefox, you can find a colour picker in the dev tools (top left of the "inspect element" tab). That mostly focuses on devs though, so all you get is HTML colour hex.

[1]: https://github.com/stuartlangridge/ColourPicker

Another tool that we use in the online mapping world that specifically supports color blindness that generates palettes is ColorBrewer:

https://colorbrewer2.org/#type=sequential&scheme=BuGn&n=3

Firefox F12 and there is a colour picker, it can work in a pinch.

But it doesn't matter for this article, author puts values in descending order for the labels so you dont really need colours.

Better yet if they put the values next to the label name too, but we can have it all.

gpick is a nice tool to do it: http://www.gpick.org

Does turning your monitor / browser into negative mode help?

It seems that to handle this you should have lines between the label and the slice instead of a legend. Google Sheets seems to do this by default but it seems to sort colours from dark to light which may make the boundaries of some colours hard to see for colourblind people. I would assume that putting the slices light-dark-light... would be optimal for the contrast between them, even for people who are not colour vision deficient.

I’ve heard people recommend https://colorbrewer2.org/ and https://gka.github.io/palettes/ for color palettes.

I also recommend Color Oracle for testing:

http://www.colororacle.org/

The chart is ordered, you don't need to differentiate the colors.

I don’t understand. If you can’t differentiate the colors, you can’t see the boundaries between segments. I think it would have been good to include tables, as well.

EDIT: I see what you’re saying now. You can just read the legend, which lists things in order. But that just gives the ordering, not the sizes of the categories.

Different colors can be differentiated, it's the three yellow colors that are similar, but don't need to be differentiated, they aren't consecutive.

There are different kinds of colourblindness. Deuteranopes are likely to confuse greens with yellows, which are consecutive here.

I usually find that JS heavy approaches can shine here, like with Chart.js. Here on the donut pie [1] you can hover with your mouse and see the name of the labels and the amount.

Where I like this approach is with big line charts like this one [2] (here it's D3 that's used). I am colorblind, and also not good at following things in general (I can have a hard time counting sequences of similar numbers), and I find charts made this way easier to read.

[1]: https://www.chartjs.org/docs/latest/charts/doughnut.html

[2]: https://observablehq.com/@d3/multi-line-chart

You should typically avoid using piecharts because humans are terrible at interpreting size/parts of a whole.

Every piechart can be turned into a barchart that communicates the findings in a much clearer way.

What really stood out in the article: It took a lot less time for C mistakes to be fixed vs non C mistakes. That's not saying C is great. More significantly most of the mistake based vulnerabilities took over over half a decade to be identified.

Not a lot, right? 2400 days vs 3000 days.

That's roughly two years, so I'd say a lot of time is accurate.

That strikes me as a bad thing. A bug that is easy to fix is a bug that could have been fixed sooner. That's exactly the kind of bug that causes the worst issues. Bugs that are hard to fix but readily identified are at least possible to work around.

I hope that's a small number. Hate to think there are as many logic-intent sorts of bugs as well.

https://github.com/1ma/CurlAda

That is why I wrote my webpage downloader in Pascal

No C vulnerabilities at all

Now you have to deal with Pascal vulnerabilities \s

Why doesn’t he rewrite it in rust then and do himself a favor going forward?

Why do you think he's adding Rust components to it?

Seems like re-writing it with extra steps.

It's "re-writing" with actual steps

I think he is being paid to, not sure if he would choose to personally.

There was a blog post a while back where he more or less said "I am being paid to add Rust".

curl is very widely used, including on platforms that Rust doesn't support. Broad support is perhaps its killer feature.

A rewrite would introduce new bugs, even if they aren't memory issues. The rewrite could end up buggier than the original.

Yeah of course, I just think instead of all this “it could be in rust talk” let’s just get it over with.

As an example of how widely curl is used, the author has posted things like the support emails he gets from people whose car or IoT device uses curl:

https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/

I love using Rust for new development but curl is _everywhere_ and a port would need to spend a lot of time copying old quirks. Given how clunky C APIs are, I’d think it’d be better to migrate more of the callers to a higher-level interface anyway.

So is making the UNSAFE FOR ALL, instead of unsafe for few?

Defaults matter.

P.D: Think if web browser were not fixed or improved because maybe somebody is using Win95. Its the same. The path to better is stop using what is proven to be bad (C/C++ is proven to be very bad!). The path to make sure niche platforms are covered is turn what is better in something more popular until it replace the old... and niche platforms use it...

This is called progress. Is how its done.

> A rewrite would introduce new bugs, even if they aren't memory issues.

OTOH, a rewrite could be useful in splitting up the problem-space as well as reducing errors. This is where Ada excels, and one nice way of splitting the problem-space could be in providing types (perhaps with provable properties via SPARK) that properly decompose the problem-space.

    -- Small, quick/dirty "back-of-napkin" design.
    Package Uniform_Resource_Locator is
      Type Protocol is (HTTP, HTTPS, FTP, SFTP, ETC );
      Type URL is private;
      
      Function Get_Protocol(Object : URL) return Protocol;
      -- other operations.
      Function Parse(Text : String) return URL; -- Text to URL.
      Function "+"(Object : URL) return String; -- URL to Text.
    Private
      Type URL is record
        --...
      end record;
    End Uniform_Resource_Locator;

> The rewrite could end up buggier than the original.

Given the properties of a language like Ada, you could decompose the problem-space into types (like above) and leverage the language properties to ensure the correctness of the program. For example, Ada mandates full-coverage on cases can so when you say `case Get_Protocol(The_URL) is ...` you have to provide for every value in the enumeration (Protocol here), and the compiler enforces this. So, every place you have a case-statement operating on a Protocol value, absent the `others` option, the compiler will error-out and point you to the location you're missing a value.

...meaning that you can update the Protocol enumeration and have the compiler complain at every location you need to fix/implement the new protocol.

This might interest you

https://github.com/1ma/CurlAda

There are much easier ways to get array bounds checking than rewriting everything in Rust.

And that solves double frees through ___?

Having worked with him at Mozilla I can assure you that he is familiar with Rust. I'm as much of a Rust fanboy as anyone, but "rewrite it in Rust" is not a simple process, and there are many tradeoffs involved. That being said, I think Rust will continue to improve on this front. Things like the GCC Rust frontend work are promising avenues to expand Rust's reach in terms of supported platforms, and tooling like c2rust will make rewrites simpler. There are also techniques like `RLBox` now that allow compiling C code to WebAssembly and running it in a sandbox which offer mitigation strategies without a full rewrite.

Reply on news.ycombinator.com