Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
iiii7926211dIt'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.
hitko2469211dThis 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.
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.
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.
Fast-Nop38653210d@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.
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.
Fast-Nop38653209d@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.
hitko2469209d@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.