| HN Mirror

On npm, the average application uses hundreds (or thousands?) of dependencies, none of which are audited by the application author. On Linux, ffmpeg uses dozens or hundreds of dependencies, but they're each trusted and audited by the Linux distro packaging the dependency packages, who would hopefully catch malware shipped in a Makefile. And whatever vendored libraries a C/C++ app bundles (so you can build it on distributions that don't ship the library or a new-enough version) are usually self-contained rather than having transitive dependencies. As a result, a C++ app's author count grows linearly with the number of dependencies you bring on (and you generally evaluate each author's trustworthiness, and hopefully skim over the library and build scripts as well), rather than polynomially in the dependency tree's branching factor and exponentially in its depth (you generally don't evaluate the trustworthiness of your transitive dependencies' authors, since there are so many and they're not shown to you when you add a dependency).

Additionally, an app's vendored dependencies don't automatically update until you choose to update them. And when you update a vendored dependency, you have a chance of finding malware when you review the diff before committing the update. The downside is that vendored dependencies introduce friction in updating your dependencies (I've experimented with extracting tarballs, git subtree, and git subrepo, and generally avoid submodules, and they're all somewhat awkward), and don't automatically receive patch/security updates like distribution libraries do.

I'm more familiar with crates.io and PyPI than npm, but I think they all work similarly (unvetted package repository allowing libraries to depend on other libraries, and transitive dependencies get pulled in when you install the library, and can be updated without the library author's knowledge). The primary difference IMO is the degree that packages use transitive dependencies vs. building/copying the subset of code they need (the average Python app uses dozens of dependencies, Rust apps use hundreds, Node apps use thousands).

My wish is that for each language, a team of Linux distribution maintainers or community members would "sign off on" a set of trusted packages, each of which depends on only trusted packages. And when a trusted package gets updated, the new version isn't marked as trusted until the maintainer verifies the diff isn't malicious. Then the language package manager would add a mode where apps or libraries can choose to only depend on trusted packages (which only depend on trusted packages, etc.).

(In the Rust world, where the compiler and package manager are developed by the same non-commercial organization, I hope the Rust organization will create the team handling "trusted packages"; sadly they seem opposed to it because they consider it favoritism, but IMO it's a good thing for Arch to package wget and curl, but not "joe's 1337 haxxor tool". In the Node world, V8 and node.js and npm are different groups/companies I think, so I don't know which organization is community-led and neutral enough to make a trustworthy host for this effort.)

Crev takes the "web of trust" approach, where everyone can choose who to trust. However, it doesn't ship a "deny untrusted dependencies" mode as part of Cargo. And as with PGP webs of trust, I haven't met any library developers in person, don't know which developers sign off on packages, and would prefer having semi/centralized institutions (like Linux distributions) who stake their reputation on the non-maliciousness of packages they ship, and allow different people to agree on which packages to trust. Having institutions reduces the responsibility placed on the individual app developer. Right now, you need to trust an distro to take responsibility for an OS, and a language team to take responsibility for a compiler. With crev, you'd have to also search for trustworthy people who've reviewed enough package that you can feasibly build apps using only those dependencies, instead of having the distro or language team provide that service out of the box.

Maybe I'm just too lazy to find trustworthy people. But currently there are not enough Crev reviews at all. Searching through https://web.crev.dev/rust-reviews/crates/, there's no mention of gtk and pipewire, and rusqlite and sqlite are reviewed but not libsqlite3-sys. And if I were to start writing reviews, would people trust me?

My hope is that Linux distributions will enforce a policy of only packaging applications where all dependencies are trusted packages (on top of reviewing the app's own codebase as usual). As difficult as this may sound, this is already the norm for C/C++ applications, where it's easy to find either distribution-packaged or self-contained libraries, and there are organized teams of maintainers selecting trustworthy packages, auditing and packaging libraries based on user demand, and telling audio libraries that require 70 packages to bind to PipeWire to clean up their act. Unfortunately, in languages where package managers and communities have embraced unvetted transitive dependencies, it's difficult to even find libraries with small or trusted dependency trees. This normalization of deviance has seriously harmed our ability to understand and/or trust the code making up our apps, and it will take changes in our package managers and community norms to restore trust.