> This isn’t an already solved problem nor is it an easy to solve one.

It is a solved problem, the solution is just politically inconvenient for us: only trust the OS vendor’s signing keys, treat them as benevolent dictator of our computing, and have them censor[0] those who we hope are malware authors, on our behalf.

Of course, there are all sorts of other problems unrelated to the provenance of the signers; npm is notorious for making basically all of those mistakes. But there absolutely is no good antimalware solution that does not require human review. There has to be someone in the mix to actually look at the code and make sure it’s nonmalicious.

Unfortunately, this also grants the person doing the reviewing power over your computing habits, in two ways:

1. They can refuse to sign a benign package on non-security grounds, such as a political disagreement with the package owners, taking offense to what the application does, or not wanting to sign a package that violates copyright in some way[1].

2. They can agree to sign a malicious package, either because they make more money doing so, because they want to compromise or extort their users, or because someone else compromised and extorted them into shipping malware.

#1 is why the App Store sucks and #2 is why alternative stores suck more. This is not a technical problem; this is a governance and alignment problem. Linux distros sidestepped this problem mainly by being non-profits with a small number of trusted developers. But it's not foolproof - they absolutely cannot review and approve every .deb package out there, especially on a nonprofit basis.

And there's nothing in Linux that requires you use this governance structure. Think about how things like Ubuntu PPAs are technically the same anyone-can-sign tragedy that makes npm a hostile environment (even if nobody has attacked them yet). There's also no particular reason why you couldn't ship a Linux distro from a powerful international megacorporation with strict lockdowns everywhere. In fact, that already exists, it's called Android[2].

Of course, you might argue that people should be more literate users and vet the packages themselves, and we should just settle for trust-the-delivery-guy. In the context of the original blog post, which is talking about PyPI packages for developers, that might make sense. But think about how many developers transitively trusted `left-pad` and got burned when that package got pulled. I do think there is room in the developer ecosystem for some non-profit entity that can vet FOSS packages.

[0] In the broadest definition of "censorship". Yes, I know I'm including what the US 1st Amendment would technically consider private counter-speech in there. If we go purely by "only governments can censor" then Steve Jobs Did Nothing Wrong, there's nothing wrong with death threats from Nazis, and Facebook should be allowed to libel actual medical journals with shoddy fact-checking.

[1] That being said, it is more common than you think for malware to disguise itself as pirated apps. If you're already violating copyright, then slipping in some malware doesn't actually increase your legal risk. Thus, blindly enforcing the worst kinds of copyright maximalism actually does sweep away some malware... at the cost of customer-hostile antifeatures everywhere.

AFAIK deliberately signing non-malicious pirated apps would probably open you up to plenty of legal challenges, DMCA 512 notwithstanding, so I'm pretty sure you couldn't provide a "bare guarantee of security" anyway.

[2] Yes, I am aware that Android supports third-party app distribution. However, the OS privileges Google apps in various ways; up until Android 12 you couldn't even auto-update non-Play apps. Furthermore, I personally would not trust most third-party app distributors as the space is extremely sketchy. It's one thing to distribute your own apps outside of Google Play, but becoming an app distributor exposes you to the conflicts of interest I listed in the main part of the post.