It's certainly impractical for every developer to vet every package they use, so much so that almost no developers vet any of the packages they use. What's needed are more gatekeepers. Repos like NPM would be well-served by coming up with mechanisms to support this. Off the top of my head, some sort of "this is safe" consensus, whereby the community can vouch for specific immutable versions of packages, that don't become the default version until they cross a threshhold. Organizations with a history of good stewardship and trusted validation processes could be allowed to skip the vetting step (e.g. things published by groups like the Apache Foundation or even corporations like Microsoft). I'm not arguing that one-man shops shouldn't be able to publish to NPM, just that there should be something like a "--untrusted" flag that's required before unverified updates are installed. And I'm not calling out NPM; every package repo has this problem.
Re:What NPM should do to stop a new colors attack
by caymanjim on Monday January 10, 2022 @05:35PM
(#29883845)
People install Linux by picking a distribution to install. The maintainers of the distributions look at the packages they're including. For example, this broken colors package will never end up in any of them, because there are gatekeepers.
Re:What NPM should do to stop a new colors attack
by toomuchtodo on Monday January 10, 2022 @05:20PM
(#29883626)
I agree we’ve built a metropolis on sand, and a large component of solving for this problem is going to be some form of trust and managing that trust (more code reviews with an audit trail of some sort, human gating of code changes using automated risk modeling, etc).
And bad actors work in companies as well. At some point you just have to trust what you are using.