alt Hacker NewsStop using memory-unsafe languages for anything unless a formal proof of safety is produced, only use OSes with strong sandboxing mechanism, make sure every piece of software is being sandboxed, etc. Or even just: “make the software authors liable of criminal negligence if an exploit occurs and they cannot demonstrate that they did everything possible to avoid it”.
It would indeed have slowed down the field immensely, but we would have avoided the chaos that is ahead of us right now.
And that sounds crazy compared to the standard we're used to, but what's crazy is that if your coffee machine explodes and harm you the makers are liable, but if your coffee machine is part of a botnet that disrupts a critical infrastructure, causing the death of people, then somehow the coffee machine maker faces literally no liability for not securing their IoT crap.
Replies
> Stop using memory-unsafe languages for anything
If you bother to check, you'll eventually notice that even "memory-safe languages" have accumulated a good share of CVEs, inclusive for memory safety issues. Check out RustSec.
But scripts written in PHP are themselves memory-safe. The problem here isn't in a particular PHP script, but rather in the underlying implementation of the PHP runtime, which was written in a memory-unsafe language.
If that's your standard, then Python isn't a memory-safe language either, since CPython is partially written in C. Same as many other memory-safe languages like Ruby, anything in the .NET ecosystem...