This is wrong as there are many other safety issues to worry about.
back
1 comments
But memory safety is one of the big ones.
Most people I know that had security incidents did not have this because of memory safety issues. But it does not matter, even without memory safety issues out of the picture, you would need to update your software and be wary of supply chain attacks.
(Actually, I can't remember a single incident where somebody I knew was directly affected by a memory safety issue)
> I can't remember a single incident where somebody I knew was directly affected by a memory safety issue
That doesn't mean the issue is nonexistent. See this article by Microsoft that shows the percentages of fixed CVEs that are related to memory safety.[1]
[1]: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...
The percentage of fixed CVE at Microsoft is an irrelevant number. It is heavily biased by 1) what gets assigned a CVE in the first place (a usability issue or a weak supply chain usually does not even though far more relevant for users), 2) what gets found and fixed (memory safety issues are relatively easy to find and verify), 3) and also by how Microsoft operates (e.g. certainly not using any modern C).
So I think looking at this with regard to what actually matters for users is completely misleading. Rust fans running around touting memory safety as the most critical thing that overrides all other considerations, but having several hundred of dependencies in statically compiled software and teaching users to do "curl | bash" is actually a disaster for security. I am not saying that memory safety is not a good thing, but this distortion of reality is harmful.
> 3) and also by how Microsoft operates (e.g. certainly not using any modern C).
Are you suggesting "modern C" is less prone to memory safety issues, and that if MS used "modern C" then that would meaningfully reduce the 70% of security vulnerabilities it claims are caused by memory safety violations?
I would say a modern style of C using proper abstractions and modern tooling is less prone to memory safety issues than C written in the style of C89.
You can appreciate Rust and hate `curl | bash` at the same time. Plenty of binaries that are just download and execute.
Of course, I just wished enough Rust enthusiast cared also about other real-word security issues enough to get this fixed: https://rustup.rs/
If you're offering a new package manager up for installation (which, Steam aside, isn't the kind of thing that's normally practical to put inside a Flatpak sandbox) on a platform where every distro has its own package manager and repository, what would you propose?
There's a reason they offer "download and run this .exe" on Windows and "download and run this .sh" on POSIX platforms.
...plus, as they mention in the tiny "other installation methods" link, none of the distro packages are official and people have a nasty habit of coming to you for support even if you didn't point them at the downstream-patched distro package they found.
Given how much distro packagers have tried to contort Rust to fit into their pre-existing `.so`-centric packaging system, I can see why Rust upstream would want to downplay that option to avoid headaches.
Let's compare what some other supplementary package managers tell people to do:
Memory corruption is among the hardest things to exploit but also the most powerful. It used to be easier before things like ASLR and NX-stack.
And 99% of the problem for memory safety and also any other issue goes away for the regular user if software is obtained from trusted sources that provide security support, because the window of opportunity for the attacker gets smaller. Anything that makes this harder (and this includes free software written in Rust) is a practical real-word downside for security.