Hacker News new | ask | show | jobs
by ok123456 816 days ago
So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
1 comments

> I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml

A few things:

1. It'd be Cargo.lock

2. Debian, in particular, processes Cargo's output here and makes individual debs. So they've taken advantage of this to already know via their regular package manager tooling.

3. You wouldn't dive into and look through these by hand, you'd have it as a first-class concept. "Which packages use this package" should be table stakes for a package manager.

> Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!

The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic.

The point is just that "which libraries does the binary depend on" isn't a problem with actual tooling.

People already run tools like cargo-vet in CI to catch versions of packages that may have issues they care about.

> The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic.

False. In the current situation, you just release a new shared library that is used system-wide.

Okay, so the analogous situation here is that you release a new version of the library, and rebuild. Done.
Except that's not the case at all with Rust.
Except it is. The system package maintainers release a new build of the package in question and then you install it. There's not really anything else to do here. There's nothing special about Rust in this context, it would be exactly the same scenario on, for example, Musl libc based distros with any C application.
Fundamentally there is no difference. In practice Rust makes things a lot worse. It encourages the use of dependencies from random (i.e. published with cargo) sources without much quality control. It is really a supply chain disaster to happen. A problem like this would propagate much faster. Here the threat actor had to work hard to get his library updated in distributions and at each step there was a chance that this is detected. Now think about a Rust package automatically pulling in transitively 100s of crates. Sure, a distribution can later figure out what was affected and push upgrades to all the packages. But fundamentally, we should minimize dependencies and we should have quality control at each level (and ideally we should not run code at build time). Cargo goes into the full opposite direction. Rust got this wrong.
And Alpine Linux is largely a mistake.
Ok well have a nice day I guess.