A lot of it is based on trust, that’s evidently true, and as such, I think it’s perfectly fine to publicly shame a maintainer who looks to have breached that trust.

Doing this for something like GNU/Linux is simply not practical, _at all_. In what world can a user be expected to do little else that simply install linux? Since you pipe, can I assume you know everything about the kernel tree?

And bad actors work in companies as well. At some point you just have to trust what you are using.

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.

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.

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).