SAN FRANCISCO, CA - In the wake of a devastating supply chain attack in the npm registry that left millions of enterprise applications compromised and billions of user records exposed, developers across the JavaScript ecosystem expressed deep sorrow today, lamenting that such a crisis was completely unavoidable.
“It’s a shame, but what can you do? This is just the price of building modern web apps,” said Senior Frontend Engineer Mark Vance, echoing the sentiments of a community that completely relies on a 40-level-deep nested tree of unvetted packages maintained by pseudonymous strangers to capitalize a single string. “There’s absolutely no way to foresee or prevent someone from taking over a long-abandoned utility package and injecting a crypto-miner into every production build in the world. It’s just an act of nature.”
Does NPM really not do cryptographic verification or is this part of the joke? I always assumed the attacks were due to a compromised key or something, but this is implying you can just push whatever you want to an NPM package if you have the author’s login?
Rust is doing pretty poorly right now.
https://kerkour.com/rust-supply-chain-nightmare
Unlike javascript, where at least it is an interpreted language people can audit, you would have to reverse engineer these binaries to figure out what they do.
This is how all language package managers work, unfortunately. The login’s security can be improved, via things like 2fa, but it’s currently very bad. Having multiple parties use keys to sign packages after reviewing all changes, is a thing unique to distro package managers, and it is why Linux distros are extremely resilient against supply chain attacks.
If you cargo install something you get source code (unless the library packages a binary, but that’s the same as if it were JS or Python or C). Rust dependencies don’t become binary until the final product.
Auditing Rust binaries isn’t much worse than auditing minified and uglified JS. I’ve done both.
I’d imagine Rust’s strict enforcement of a few specific patterns makes the assembly more predictable than C/++ where you can do literally anything?
npm does actually support signing and provenance (tracking how the package was built), so in some ways it can be more secure than other package managers. https://docs.npmjs.com/generating-provenance-statements
If you use one of the CI/CD systems they support (currently Github Actions and Gitlab CI), it can attach a signed attestation to the package stating the commit hash that was used to build the package, along with the steps taken to build it. This is combined with trusted packaging using OpenID Connect with short-lived tokens that are only obtainable in the correct CI environment, rather than using access tokens or username and password.
It only supports some CI systems because they have to guarantee that the connection between the CI system and npm is secure.
Some of the recent issues have been attacks on the CI system, rather than npm itself. For example, a Github Action that’s only supposed to run for commits to the main branch, but unintentionally runs for some subset of pull requests too.
Of course, all this stuff is optional, and pushing to npm directly from a developer’s computer still works and is still not verifiable at all.
I think the best approach is what Flathub/Flatpak, F-Droid (Android) and Composer/Packagist (PHP) do. You provide your repository URL, and they build the code on their end. Packages are always guaranteed to be built from code in the repo.
Debian Linux is also moving towards requiring repeatable builds, meaning that a package built from source should be byte-for-byte identical to the package in the repo.
Cargo distributes libraries as sources, not precompiled objects.
Yes, that is true.
Thought, even this remains problematic because cargo does execute build/compile time scripts, unsandboxed, that can be used to do malicious things, similar to the problems with npm.
But “you would have to reverse engineer binaries” is objectively false, since packages are source.
I agree on your other point, but you really should edit the misinformation.
The recent attack didn’t have to do with cryptographic signatures. It was a supply chain worm, with GitHub Actions being the vector. https://snyk.io/blog/tanstack-npm-packages-compromised/