- cross-posted to:
- hackernews@lemmy.bestiver.se
- cross-posted to:
- hackernews@lemmy.bestiver.se
You must log in or # to comment.
Another day of vaguely pointing at Javascript when asked where the circus is.
ai! slop!!
oh, and the text is pristine, the misinformation nexus is here!! fsm help us allInterestingly, 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?
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
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.
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.
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.
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.
EDIT:
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
I just went through the article and I don’t think I agree with the assessment that “Rust is doing pretty poorly right now.” It feels disingenuous, given the content of the article you linked:
826 crates match their upstream repositories at the revision they were built at. 74 crates have revisions that cannot be found in their repositories, whether due to later squash merges, rebases or revisions simply not being pushed. 73 crates do not have VCS info, either because they were built with old Cargo versions, built with --allow-dirty, or not built from a repo clone at all. 77 crates do not declare a repository in their Cargo manifest. 7 crates would match their upstream repository but for one or more symlinks being incorrectly handled. 3 crates declare repositories that do not exist. 3 crates have submodules that do not exist. 3 crates cannot be found within their repositories. 3 crates cannot be built due to cargo package errors. … Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.
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?
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.
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/
It’s funny that we’ve had SLSA4-compliant package managers for 25 years, but we leave juniors un-mentored and this is what they build as they self-teach … over and over and over.
Hilarious idea brought down by the AI slop thumbnail. The vulneráéilíties on that screen sure look OOTΓKAL.
There’s another problem which is that you can only donate about $104,000 to a federal candidate’s campaign but you are allowed to independently campaign for that politician using unlimited funds. Third party campaigning shouldn’t be allowed. It’s been ruled a matter of free speech, that if Michael Moore wanted to make a documentary critiquing health care in the US, that is his right. But some people will make documentaries filled with lies. It might be difficult to control what wealthy people do with their money and what they say, but that doesn’t mean you can’t try.
