Rust's Security Circus

I may hate the community, but I give Rust this: it’s safer than C. And C++. And maybe a few other languages, but that’s it. So, when it comes to choice regarding my future web-hosting server, I was really considering a web server written in Rust.

SWS, or Static Web Server, is perfect for what I do; this blog is powered by hugo, a static site generator, and I don’t need more than a static webserver. SWS sounds perfect. It’s written in the safest language on the planet, Rust, the language of Gods, I guess, since there’s impossible to do anything wrong in Rust. And for a second there I actually considered installing SWS on my server and…

I opened the Changelog. Every release is a security update. Welcome to the security circus!

Here’s the problem, every release of SWS is a security patch. There’s always a Bugfix/security dependency updates including tokio, rustls, serde, toml, zstd, clap and other crates (the message differs, but the idea stays). Each release has this; not only each release has this, but I fear that these guys don’t really understand the consequences of having such an inclusion in the changelog.

1. There’s no security fix for my current version

Say I have downloaded version 1.x two months ago. Version 1.x has features A, B and C which I like. Version 1.x+2, which is the current one, changed feature C to C++, but still names it C, and that one I don’t like. I want to keep version 1.x with feature C that I like. I’m two security patches away from the current state, so my server is vulnerable. There is no security for my current version. NONE.

Workaround 1: but others are equally unsafe

You’d say: „But there’s no security update for your old nginx or apache” (the Rust community tends to blame everyone else but themselves). Actually, there is. When a dependency has a security update that dependency is updated, and all is required is a service restart at most. The server itself doesn’t need to be updated, because it still links to libsecurity-vulnerability-1.2, but now it’s libsecurity-vulnerability-1.2.4 instead of 1.2.3. And not only nginx is updated, but all the services requiring libsecurity-vulnerability are updated and secure.

Workaround 2: Of course you need to download the new version

Remember, I need version 1.x because it has feature C, not feature C++. I might not want feature C++. I might reluctantly update to feature C++, but it’s not pleasant, that’s why I’m using Rust, right? (Kidding, I love C++). But I’m not really safe with the new version, see problem below.

Workaround 3: Of course you need to recompile by hand with updated dependencies

Listen, kid, I don’t. I could, but I don’t; I want my system to work, I don’t want to recompile it everytime I need to patch something. I don’t deploy yocto or gentoo, I deploy a distribution that is security-vetted by someone who actually does this for a living. I’m no security analyst either, how the fuck would I know that there is a bug in crate bzzzzrt “10.32”. Excuse me, in the awesome crate bzzzrt “10.32”. How many zs where there?

2. There’s absolutely no security fix for the currently released version

Now, you may think that wow, amazing, you’re on the latest and greatest, you’re safe! Maybe for something up to 5 minutes or so, maybe if I’m lucky. Because statistically, if they update monthly at least 5-6 crates for security fixes, that means that it can take anywhere from 5 minutes to 10 days for the release to be outdated security-wise. By the end of the month I will surely be a few security patches off. So the experience of running this Rust service is basically putting on your pants with no belt and walking without pulling them up until you’re with your pants to your knees. Then, come next month, you pull them back up. Maybe.

Workaround: Compile from HEAD! we’re always up to date!

Listen, kid, how the heck can I actually vet your awesome crate bzzzzrt “10.33”? I’m a guy who publishes content, why the heck do you want me to vet your hundred of awesome crates and their cratependencies? Why should I ever do that? Who does that? Do I compile each HEAD update for your main?

3. There’s absolutely a supply chain attack in my future

Have you counted the zs? I told you, it’s crate bzzzzrt, not bzzzrt!!! You moron, go use C++ if you can’t use the awesome divine Cargo, gift from Gods and all.

Cargo is a security threat. Is a security threat for users, is a security threat for the developers. How long until the reasonable-name-space will be clogged with abandoned crates that are in vulnerable states? How long until the crates will be replaced by other crates, when bzzzzrt will replace bzzrt and nobody ever counts the damned zs, it’s supposed to be threee!!!

Cargo is supply-chain attack waiting to happen. If not on me, the user, since I don’t (I really don’t) want to compile stuff by hand, then definitely on the developers. Heck, it’s capitalism, baby, why not pay the bzzzrt guy to do work for some ominous organization, like Kremlin Corp. or Microsoft? Oh, this already happens? Oh, noes! Anyway….

This is a security circus

I dislike Rust’s community a lot, but I don’t necessarily dislike the promise of what Rust wants to be. Safer. Yet it looks like no standing Rust executable is ever safe. If you have in your foundational tech security patches monthly then something is wrong there. If you can’t freeze a binary executable and say „this is safe” then where’s your promise going? This is unsafety by design, and any response you might have, any executable I produce that has Rust crates in is vulnerable by default.

So next time a rustacean harasses you into how safe Rust is, show him the changelog of a static web server. Perhaps there’s stil work to do, dudes, maybe work on your fundamentals, what do you say?

PS: I would end with a joke like „me and my friends we are greeting each other with Fuck Rust”. It’s a bad joke in bad taste because obviously I have no friends. But as always if you want to complain about stuff there’s social media. I rarely check but you can ping me on twitter.