You can have the best test coverage - even building your own fuzzing framework on the way.
You can have top notch devs adhering to state of the art development processes.
You can have as big a community and as well-funded a bugbounty program as you want...

All of that doesn't matter if you have chosen the wrong language:
https://googleprojectzero.blogspot.com/...

This would just have been an out-of-bounds exception instead of a buffer overflow using an attacker-controlled payload in any memory-safe language.

Language choice matters!
Choose wisely!

It's not a language choice matter. By your logic, it seems, some languages are strictly worse for anything, than the others. But that is false.

@iiii That's what Rustaceans argue with regard to C/C++. That's why they made a language to replace C++, but completely forgot about C.

This isn't a problem with the language; this is a problem with mindless reliance on (flawed) tests. A memory-safe language might prevent this problem, but that doesn't mean similar errors don't happen when developers rely on tests instead of considering the purpose and possible uses / side-effects of their code. The so-called "best practices" primarily solve the problems which arise from lack of organisation, not problems caused by devs not paying enough attention to the code they write. Not being aware of that is an increasing problem as more and more "fresh" devs and "better" tools are available on the market.

@iiii
Well, you certainly don't want to write the memory management and process sheduler of an OS in a memory-safe language.

But going for ASM, C or C++ to do Crypto is like using thermite to heat your home.
You can certainly do it and if you are careful and always vigilant, it will work just fine without any incidents.
But if it something goes wrong, there is a real high chance that it goes wrong horribly.

Not every tool is the best tool for any job.
Not every language is the best choice for making every software.

Non-memory-safe languages are harder to use - and additionally promote a lot of the bug classes that are "just" causing a DoS in memory-safe languages to juicy RCE.

@hitko
Humans aren't flawless. Devs are humans. So devs aren't flawless and therefore write code that is not flawless.
So there will be bugs. You can choose a language where that bugs will be exploitable for DoS or where they will be exploitable for RCE.

You have chosen RCE.

@Oktokolo by your logic those "safe" languages have flaws as well

@iiii
Of course they have flaws. Shit tons of them.

It isn't about reaching perfection, but at least trying to go into the right direction.

There is a difference between having N serious bugs leading to DoS exploist or having most of these being promoted to RCE because every out-of-bounds write can overwrite important data or return addresses on the stack.
Memory safety isn't just a convenience feature. While it makes writing code less cumbersome, it also reduces the severity of the highest-profile exploitables currently seen everywhere in this industry.

You can downgrade almost all RCEs just by changing the language. They don't go magically away but become downgraded to DoS opportunities. But a DoS is way less severe than an RCE.

With all the code quality theatre already in place, we probably wouldn't even have heared about the linked bug at all. No one cares about worker process respawns... The fix would just be included in the next regular release.

@Oktokolo The bug wouldn't have happened either in idiomatic C++ where you don't use unions, and neither in idiomatic C where pointer and length should always be handed over.

It's basically using non-idiomatic C in a C++ base here.

@Fast-Nop
Yes, bugs only happen, when someone does anything stupid.

Amnd humans do stupid things. All of them - including me and you.

Just don't write bugs isn't an actual real world solution.

@Oktokolo The actual question is why someone who writes non-idiomatic C in a C++ code base gets around to write important crypto stuff in the first place.

OK, Rust would have prevented at least that from happening thanks to its very high entry barrier that keeps most devs from writing any code in Rust that would compile - and no code, no applications as likely result would maybe be the better option.

@Fast-Nop
I don't know, why humans do stupid stuff. But i know for sure, that they do. All of them. Some do it lesss often, some more often.

You can replace the dev who wrote non-idiomatic code. The next one might just forget a bounds check or do a use after free or other stupid stuff.

Or you remove the unneccessary ability to write non-memorysafe code as you just don't need it for the task at hand.
It is about the right tool for the job and using basic safety mechanisms preventing or mitigating some of the most severe accidents.

@Oktokolo I see your point, but we don't have a solution for the problem. What we have is a simpler and safer C, but with GC - or an even more complex kitchen sink language as alternative to C++.

You don't really think that people who write bad C code in a C++ base would use that, do you? Because if they were, they would have even more been able to use either idiomatic C or C++, in both of which cases this wouldn't have happened.

@Oktokolo The problem is that memory-safe languages only check for access, not for other issues with memory management, like integer over / underflow.

Rust only monitors integers in development mode, meaning no exception will be thrown on production when someone tries to exploit it. The developer will be none the wiser unless they actually pay attention to memory management and test for possible overflows.

On the other hand, Python will gracefully allocate more memory to prevent integer overflow but won't prevent exploits where such value is passed to some native library.

Therefore, both of those leave plenty of room for RCE if the developer ignores memory management, even though they're considered among the most memory safe languages.

And then there's the psychological effect; when the dev is aware their language doesn't offer memory safety, they'll pay much more attention to possible problems than when they use a language that generally handles memory sufficiently well.