Watching language package managers reinvent everything distribution package managers have been doing since the 90s has been as fun as watching crypto people reinvent financial regulation.
The publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few.
(This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)
And then who watches the watchmen? Chains of authority can always be questioned. I think GP is suggesting that the package management platforms themselves provide the verification if they want to stay in the business of being the de facto source.
This comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.
They are literally solving the same problem, it’s just that distro packages operate on a lower level and thus receive more scrutiny. There have been plenty of examples of poisoned Linux packages, both at the source level and at the package level.
A distro package manager provides access to a small set of packages that the distro thinks you might like. A language package manager provides access to the full set of packages. The language level package manager is solving a more ambitious problem.
Distro package managers don't solve the problem they just punt on it, saying "you can add an unofficial source but you're on your own to maintain security". I agree with GP that the comparison is tiresome.
If you want to curate a language package manager, there's nobody stopping you. Curation is a product that can trivially be built on top of an allow-by-default platform. If you want to make "NPM, except we've vetted all the packages", you can just do that, today, and you can even make use of all the OSS packages that already exist on NPM. Your hypothesis is that people want this, would value it if it existed, and would maybe even pay for it. So what's stopping people? Anyone who hasn't thought deeply enough to answer this question doesn't have the privelige to say "just curate it, what's the problem?". Curation isn't that simple, as any distro package manager volunteer would tell you.
> Anyone who hasn't thought deeply enough to answer this question doesn't have the privelige to say "just curate it, what's the problem?". Curation isn't that simple, as any distro package manager volunteer would tell you.
Your logic is self-defeating. How are distro volunteers going to know that you are interested in this topic if, by your logic, you don't have the privilege to ask them in the first place?
But I don't think that asking needs any privilege. I'm going to ask again: Why not? Or worded differently: What is stopping language package managers that is not at the same time stopping distro package managers?
I agree it's tiresome that language package managers continue to be an embarrassment.
But actually your comparison is incorrect, distros are nothing like app stores. App stores are full of the same junk and malware as language package managers. Distros are vetted collections of real software that use modern best practices to secure the software supply chain.
Being unable to rotate the same weak RSA key for over a decade because it was too operationally cumbersome[1] does not strike me as “modern best practices.” I also don’t think any Linux distribution package maintainer would make a legally binding claim to have “vetted” packages: the filter is reputational, not a strong guarantee that the package is not malicious. The xz incident demonstrates that tidily: the only reason it was caught it because it was noisy; the package itself was presumed to be safe.
(This is, to be clear, fine. But we should be clear-headed about what package distribution mechanisms actually provide in terms of guarantees.)
Two security incidents over decades is proof that distros are more secure, not less. Every other system for distributing software has weekly security issues.
> what package distribution mechanisms actually provide in terms of guarantees
1) Mirrors of cryptographically signed files to verify integrity (both the source code and the built packages), 2) a secure software supply chain & SBOM, 3) reproducible builds (for some distros), 4) humans independent of the authors vetting admittance of new packages to prevent obvious malware, 5) stable branches of packages that work together (preventing need to constantly upgrade, a source of new vulnerabilities), 6) backported security patches (necessary if you can't upgrade), 7) package maintainers fixing glaring security holes in the default installation methods of software to prevent the distro from having new vulnerabilities.
To be clear, the RSA key thing isn’t really about it being a security issue
— that’s a part of it, but the bigger point was that it reflects structural failure/inertia that’s commonplace in distribution packaging.
(I am not a hater of distribution packaging, either. But I typically find comparisons between it and language packaging lacking, because the two have very different trust topologies.)
(This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)