About 40% of #curl's vulnerabilities could have been avoided had we not used C.
@bagder 100% could've been avoided had you not been using any language!
@lkundrak that is a lot of percent! 
@bagder fun weekend project: rewrite curl in pseudocode
@bagder which does not necessarily mean that other languages would have prevented _all_ the mistakes, but probably some of them, I guess. 
Thanks for the figure anyway!
@bagder not sure how much traction this would gain but there an initiative to make C safe - https://www.safe-c.org/
@bagder where I can I do further reading on what’s defined as a C mistake?
https://curl.se/docs/security.html explains:
The flaws listed as "C mistakes" are vulnerabilities that we deem are likely to not have happened should we have used a memory-safe language rather than C. The C mistakes are divided into the following areas: OVERFLOW, OVERREAD, DOUBLE_FREE, USE_AFTER_FREE, NULL_MISTAKE and UNINIT.
@bagder What qualifies for a C vs non-C mistake?
@bagder strong evidence for a Visual Basic rewrite imo
@bagder@mastodon.social something something rewrite in rust
@juliank @gullevek @maia first, I don't think the premise that speed is unimportant holds. Then, I don't think there is any other language than rust that would be close to viable (and even that does not even support half the platforms curl runs on). Also, don't forget footprint.
But sure. It is just code.
Paid 
@bagder but then it would have been only "URL" 
@bagder It's much lower than what Microsoft published in 2019 (70%). Any ideas why?
@flakm probably because their number had a different set of caveats and conditions, or something else...
@bagder, anyway, it's fascinating to see, especially given the difficulties in finding champions for the hyper backend.
@bagder Written as a Perl script, these CVEs would have been prevented.
Among many other things…
@bagder that means you are at the low end of the industry average, ie. curl has less memory safety bugs than expected
@bagder then we would have 40% vulnerabilities in $Other_Language.
you need an expert in that language + the same person being security aware (in full) to drastically reduce this number.And this person has to have fun writing code used y everyone while getting blamed by everyone when there is a small mistake or vulnerability. And these days, getting annoying Vulnerability reports created by KI by people who think they are good. I am grateful that Daniel uses his spare time to develop curl.
@bagder One could look at your contributions to curl and say that we could've avoided X% of security bugs, or indeed, all bugs, if we simply sent you on a long vacation somewhere without access to a computer 
@bagder what other language would you use, and what would be the implications in terms of coverage and performance ?
@DoctorDNS the only real alternative I know of is rust, and that has nowhere near the same platform coverage as C
@ITwrx well for one thing I didn't know it existed until just now...
I started in 'C' 48 years ago. So, #curl could probably be ported back to 1970s platforms.
I understand the lust for Rust. Perhaps we must trust Rust to avoid malloc bust and it just leaves other languages in the dust.
But 'C' is of an entire class of languages the father and mother. I'm as close to it as any brother. It's simple and fast, easy to learn, and super portable.
People used to compete at writing Small 'C' compilers that could self-compile on microcomputers. Can you do that with Rust? Decades ago, 'C' was the only game in town and today it doesn't deserve a frown.
We had APL, COBOL, FORTRAN, assembly, BASIC, Lisp, Pascal, and 'C'. Hm. Which to use for portability? Decisions, decisions. UNIX went with 'C' and the rest of the world followed. Until C++ we were forced to have swallowed. But that is another story.
Rust can't even be built offline without gymnastics [which my own Linux distro admittedly supports]. Even if curl were started today, given the fact that it's needed and used everywhere, Rust wouldn't necessarily be the logical choice. But excuse the comment as I'm nearly asleep and this is simply a casual voice.
