Supply-chain-attack risk [LWN.net]

Supply-chain-attack risk

Posted Feb 12, 2025 19:43 UTC (Wed) by jmalcolm (subscriber, #8876)
In reply to: Supply-chain-attack risk by excors
Parent article: Rewriting essential Linux packages in Rust

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 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 (subscriber, #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.