[weinzierl]

"exactly the same software supply chain problem"

While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified.

There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with crates.io.

There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run

    cargo vet

to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number.

[1] https://news.ycombinator.com/item?id=45170687

[inbx0]

The main issue there is that the maintainer lost access to their account. Yanking malicious packages is better, but even just being able to release new patch versions would've stopped the spread, but they were not able to do so for the packages that didn't have a co-publisher. How would crates.io help in this situation?

FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.

1: https://en.wikipedia.org/wiki/Npm_left-pad_incident

[lukaslalinsky]

I'd argue it's more of a culture thing, not technical thing.

In both JavaScript and Rust, it's normal/encouraged to just add a tiny dependency to the package manager. The communities even pride themselves, that they have such good package managers to allow this.

It's this "yeah, there is a crate for this tiny function I need, let's just include it" mentality that makes the ecosystem vulnerable.

People need to be responsible for whatever they include, either pay the price by checking all versions up front, or pay it by risking shipping a vulnerable program that it's much harder to retract than a JavaScript frontend.