Supply-chain-attack risk

Posted Feb 12, 2025 16:46 UTC (Wed) by excors (subscriber, #95769)
Parent article: Rewriting essential Linux packages in Rust

> There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take".

This sounds unfortunately similar to Lord Farquaad from Shrek: "Some of you may die, but it's a sacrifice I am willing to make". The developers choosing to add convenient dependencies aren't going to be the ones suffering the costs of any such attacks, so I think there's some misalignment of incentives.

Hopefully any companies or large projects making use of this will be aware of the risk they're taking on, and will contribute to the tooling and code review and maintenance efforts needed to mitigate it. (Is there much activity around cargo-crev/cargo-vet nowadays, and is there anything better than that?)

Supply-chain-attack risk

Posted Feb 12, 2025 19:17 UTC (Wed) by lunaryorn (subscriber, #111088) [Link] (1 responses)

As far I know Google and Mozilla actively use vet and routinely audit crates, and some other ecosystems (eg Gnome) at least plan to. For non-commercial projects it's always a matter of resources tho, auditing 3rd party code isn't exactly fun after all, not something that folks enjoy doing in their free time. Ideally, someone like Microsoft who are apparently using uutils in one of their products would work towards vetting the dependency tree.

That said, I believe that adding cargo-vet to Rust project is universally a good idea, even if dependencies are routinely exempted. At least it makes the cost of dependencies visible, and helps to separate the big and trustworthy crates (eg libc, rustix, Tokio, etc.) from small. little know dependencies which need a closer look.

Supply-chain-attack risk

Posted Feb 13, 2025 9:17 UTC (Thu) by taladar (subscriber, #68407) [Link]

I would generally consider the big ones the ones that need a closer look in terms of the question if you actually need them. Small dependencies have a high likelihood that you use a significant part of their functionality while big ones tend to be the ones where you might just use a small percentage and pull in a large tree of their own dependencies with them that are unrelated to what you are doing.

Supply-chain-attack risk

Posted Feb 12, 2025 19:43 UTC (Wed) by jmalcolm (subscriber, #8876) [Link] (9 responses)

I am not sure that I totally agree that "developers choosing to add convenient dependencies aren't going to be the ones suffering the costs of any such attacks". With that logic, developers have no incentive to prevent bugs in their code. After all, they are not the ones that are going to encounter them.

Supply-chain attacks are a legitimate concern and I completely agree with your second paragraph. That said, there are benefits and I would like to see solutions around how to do it rather than treating having distributed dependencies as a design flaw.

I mean, we could say the same thing about dynamic linking (and some do I realize) or having any dependencies at all. I mean, I hope that the users of all software realize the risks that they are taking when trusting some random C library or C++ compiler to provide foundational functionality to the applications that they compile. Reflections on trusting trust I guess.

Supply-chain-attack risk

Posted Feb 12, 2025 19:54 UTC (Wed) by jmalcolm (subscriber, #8876) [Link]

By "random C library", I mean standard C library (eg. glibc, musl, BSD libc, Solaris libc, MS CRT, libcmt, runtime.c, etc). Similarly for the C++ standard library (often provided by the compiler).

Supply-chain-attack risk

Posted Feb 12, 2025 21:39 UTC (Wed) by excors (subscriber, #95769) [Link] (7 responses)

> I am not sure that I totally agree that "developers choosing to add convenient dependencies aren't going to be the ones suffering the costs of any such attacks". With that logic, developers have no incentive to prevent bugs in their code. After all, they are not the ones that are going to encounter them.

I think the same logic arguably does apply in that case too, and explains why developers have kept using C for so long. There is certainly _some_ incentive to prevent bugs in their code - pride, reputation, contracts, etc - but the developers aren't the people whose hospital is disrupted by ransomware exploiting a code execution vulnerability in some packet parsing code. If they felt those consequences directly, they might have been more eager to adopt memory-safe languages decades ago.

Many are adopting Rust now, but I think that's not primarily because of memory safety: it's because Rust is generally a much nicer language to work in than C/C++, with a helpful type system and good performance and modern package management and IDEs and all the other stuff that developers enjoy. The memory safety is a compelling bonus, but I believe very few people would use Rust if it wasn't better at everything else too.

Regarding third-party dependencies, C/C++'s lack of good package management means developers face a significant cost to pulling in dependencies: you've got to download tarballs and fight with incompatible build systems and keep on top of API changes and do it all differently for Windows and it's a big pain, so you're likely to limit yourself to a few widely-used libraries that are too large and/or too tricky to write yourself (and are therefore probably maintained by a team). For anything not so large/tricky, it's easier (though still a pain) to rewrite it yourself inside your application, or just remove the feature from your application because it's too hard to support.

It's a happy accident that the cost to developers (caused by poor package management) correlates with the cost to users (from the wider supply-chain attack surface), so the incentives are aligned and it works out okay in practice. But Rust greatly reduces the cost to developers of adding a tiny dependency (or 300) from some random guy on GitHub, without reducing the risk to users from each dependency, so it creates an imbalance that needs to be addressed somehow. Hopefully cargo-vet helps by both increasing the cost to developers (not much, but they're at least aware of the lengthening code review backlog every time they add a dependency) and reducing the risk to users (when any code reviews are actually performed).

Supply-chain-attack risk

Posted Feb 12, 2025 22:19 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

One good feature of cargo vet in this respect is the ability to import trusted audits and maintain a registry of significant auditing entities; this enables a "big" entity who cares (like Google, for example), to publish a list of audits they've done that smaller projects can import.

Assuming that big projects adopt cargo vet, this allows smaller projects to "ride on their coattails" and shrink the exemptions list by trusting Google, Mozilla, or other big names to provide audits.

Supply-chain-attack risk

Posted Feb 12, 2025 22:48 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (3 responses)

The next incremental improvement will be adding gpg style "web of trust"; you trust people you know who vet their dependencies, and recursively trust the people they trust (by an amount that falls off with distance, people that trust them, what have you).

Couple that with tools that show you "you have x dependencies that haven't been sufficiently vetted" (or have had significant changes since then), and we could efficiently farm out the auditing.

Supply-chain-attack risk

Posted Feb 13, 2025 0:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Not really a great idea... You'll be trusting Kim Jong-Un and Putin after about 3 levels of handshakes.

Supply-chain-attack risk

Posted Feb 14, 2025 23:23 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I don't know…having them review Rust crates for issues might help distract them from their other more…problematic behaviors.

Supply-chain-attack risk

Posted Feb 13, 2025 10:14 UTC (Thu) by farnz (subscriber, #17727) [Link]

That already exists, separately to cargo vet - it's provided by cargo crev, which aims to crowdsource review.

Supply-chain-attack risk

Posted Feb 13, 2025 9:20 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

There is a hidden cost to those internal versions of functionality that could be a well vetted and tested dependency too though, they are just generally not considered by projects trying to argue that any dependency is bad. It is much more likely that your half-thought out internal code you just wrote for a single user has some bad design flaws and security holes and critical bugs than a library used by thousands of others.

Supply-chain-attack risk

Posted Feb 14, 2025 6:19 UTC (Fri) by raven667 (subscriber, #5198) [Link]

true, that's why you have to weigh the cost of writing your own in-house utility library vs accepting an external dependency tree and it's a judgement call specific to yourself and your team's capability on which you choose. having a read through the library you are considering can help clarify if its something that adds sufficient value, and extends your capabilities or if it's over-complicated for what you need, a future liability for you, and a more focused in-house tool that uses the built-in functionality of the language runtime would be better. Either way you aren't exactly building the universe from scratch, you are still depending on the language, operating system, kernel, hardware, etc. built by tens of thousands of people, no one is writing code by manipulating magnetic flux with a steady hand or anything.

Supply-chain-attack risk

Posted Feb 14, 2025 6:56 UTC (Fri) by hsivonen (subscriber, #91034) [Link]

Check out the “Audit” tab for the crates that you find interesting to spot check on https://lib.rs . The popular ones tend to have an audit from Google, Mozilla, or the Bytecode Alliance. It also shows whether an old version has been packaged in Debian or Guix at some point.

Of course, being packaged for Debian involves less auditing than people generally believe, but it’s somewhat inconsistent to believe that C code becomes trustworthy by distro packing and not believe the same of Rust code.

(Furthermore, dependencies don’t tend to be random crates from random authors but there’s a cluster of popular dependencies by people who have had community name recognition for a while.)