Item — HN Reader

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)

2 comments

> 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:

https://brew.sh/

https://nixos.org/download/

https://chocolatey.org/install#individual

https://store.steampowered.com/about/

Sorry, that others are equally bad is not an excuse, and also not that Rust's design makes it more difficult to package. Either you care about security or you don't.

My point is that your argument is comparable to faulting Ford for making cars disposable with crumple zones when nobody else has found a better way to meet the crash-safety requirements while satisfying the other requirements too.

As for "and also not that Rust's design makes it more difficult to package", give https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx... a read.

TL;DR: It's not a Rust thing. C++ suffers from the same problem when you use templates in your APIs... it just emits a .so file with no contents if you expose only templated APIs. It's fundamentally a problem of "Unless you're willing to spend Swift-level engineering money and still accept compromises Rust and C++ can't afford, dynamic linking in the presence of monomorphic generics is a problem even research languages haven't solved".

...same as the warts in async Rust. What you're seeing is a cutting-edge language slamming up against the limitations of what cutting-edge programming language research has figured out.

At least, with Rust, you've still got the dependency tracking and automatic RUSTSEC advisory tooling you don't get with header-only C libraries.

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.