this post was submitted on 16 May 2026
156 points (97.6% liked)

Programmer Humor

42235 readers
3 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] HiddenLayer555@lemmy.ml 20 points 6 days ago* (last edited 6 days ago) (8 children)

Interestingly, developers in ecosystems like Go, Rust, and those utilizing native Web APIs—where robust standard libraries drastically reduce reliance on third-party code and strict cryptographic verification is built into the core toolchain

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?

[–] moonpiedumplings@programming.dev 16 points 6 days ago* (last edited 5 days ago) (6 children)

Rust

Rust is doing pretty poorly right now.

among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.

https://kerkour.com/rust-supply-chain-nightmare

Rust programs that are compiled with cargo, when compiled as dependencies of another program or when compiling a binary itself, can execute arbitrary code via build time scripts, and they are executed unsandboxed. This is a security nightmare.

push whatever you want to an NPM package if you have the author’s login

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.

[–] dan@upvote.au 4 points 6 days ago* (last edited 6 days ago)

This is how all language package managers work, unfortunately

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.

load more comments (5 replies)
load more comments (6 replies)