> The 2FA nonsense does basically nothing in practice (vetting will not and should not magically go away), and only adds an undue burden on developers.
This is true, but to play devil's advocate, how many HN articles have we seen where X critical NPM package had been compromised by a malicious user who gained control of the package maintainer's account? There are many examples of this. If a new package deployment system were to launch in 2022, I wouldn't be surprised if 2FA was required for all publicly listed packages, full stop, not just critical ones. Viewed through that lens, it really isn't that unreasonable.
That said, I think full power should be in the hands of the developers who maintain these packages when it comes to the actual content of the packages. Package systems should not be editorializing. If the author of [insert major package here] wants to upgrade a version that replaces the whole package with a console animation of a turtle, that's his/her choice as a developer, and simply should be viewed as a "breaking change". Intervening in THOSE scenarios I view as completely out of control on the part of package ecosystems. Let people leverage their creations however they like. Your trust is supposed to be in the maintainer. If they aren't trustworthy, you shouldn't use their software in the first place. If they decide to go in a new, breaking direction, that's their decision. Caveat emptor.
These scenarios though, are starkly different from scenarios where the package maintainer's own intent is subverted by a malicious hacker / user. That's a whole other can of worms, and I agree we need better controls to protect all packages from these types of scenarios.
All major repositories editorialize to some extent, they would be awful if they did not.
For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI.
Generally speaking, though, PyPI does not concern itself with the contents of the packages shipped through it as long as they are reasonable packages. If a project wants to break compatibility, then that's on them. We strive to let projects manage themselves, in whatever way they think makes the most sense.
> For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI.
Where this breaks down and gets tricky I feel, though, is when you get into examples where the package maintainer makes the newest version essentially useless (but in an otherwise harmless way) in protest of some grievance. I think this is a perfectly legitimate action for a maintainer to take as long as they aren't literally installing malware or opening up security vulnerabilities. Package systems stepping in in these scenarios and "bailing out" all the companies that rely on the package by taking it over are effectively silencing the maintainer. My smell test for this is if the ISP or hosting provider wouldn't yank it, neither should the package system. Hosting providers will take down malware and illegal content, but they aren't going to do more than that, and that's how it should be imo in package systems. I think the benefit of developers' voices not being silenced vastly outweighs the humorous scrambling of a bunch of companies who failed to lock their version numbers for a few short hours. The same scramble happens all the time with real-world breaking changes anyway. If the maintainer wants to effectively yank their project, they should be allowed to do so. Otherwise you never really know if you are getting the maintainer's code, or whatever the package system decides should be the maintainer's code, which breaks the trust contract upon which package systems are built.
This is another reason it's great that a lot of languages, like Crystal for example, have adopted a decentralized model.
PyPI doesn't currently prevent deletions at all, so a maintainer can just flat out delete their stuff if they want. Though we are discussing if we want to tighten that up at all.
I would say that in the > 10 years of time I've been an admin on PyPI and even longer that I've been involved in Python's Packaging, I've never once seen anyone, but individuals placed front and center in who we're attempting to serve first and foremost.
Businesses and other large orgs do come up from time to time, and we've generally been pretty good at making decisions that allowed those businesses to solve their problems on their own, without requiring the rest of the ecosystem to do it for them. In other words, our features we add for businesses tend to be unblocking them from being able to implement something they want, rather than taking on the responsibility of whatever thing they want.
Critically, and something I forgot to mention, when the package system says it's from X developer, but they are actually serving some alternate content because editorially the package system has decided to override the developer's most recent version, saying it's from the developer is simply a lie, and is disgusting.
Odd but serious question: could there be ways to distribute versioned software that doesn't require management of developer accounts (and the associated time-and-effort costs related to account takeovers)?
Not if the goal is to avoid vetting each new version as if it were a completely new dependency. The whole reason for the current system, and the very idea of new versions of "the same software", is that we want to be able to rely on the reputation of a project to make certain decisions. For example, we trust Linux 5.11.1 to be non-malicious and to be mostly stable etc largely on the reputation of the Linux project. We don't go around vetting the code of such s project except in efemer specific niches.
If we don't trust the provenance of the code we're getting though, that reputation becomes irrelevant. As such, this is a problem of identity assurances and access management, it can't be solved otherwise.
Ok: you've provided two requirements that I agree with:
- It should be possible to compare between two releases (I'd personally like to see a code diff, ideally with a complete path of the commits involved)
- Providing a reputation visibility mechanism (for publishers? author(s)?) across a series of releases is important
Those don't require user accounts necessarily, though. And responding to the end of your message: identity assurances, yep, those seem necessary; access management, I'm not so sure.
Access management is required to have identity assurances. If there's no way to ensure someone's identity is secure, how do we know it's them in the first place?
This is true, but to play devil's advocate, how many HN articles have we seen where X critical NPM package had been compromised by a malicious user who gained control of the package maintainer's account? There are many examples of this. If a new package deployment system were to launch in 2022, I wouldn't be surprised if 2FA was required for all publicly listed packages, full stop, not just critical ones. Viewed through that lens, it really isn't that unreasonable.
That said, I think full power should be in the hands of the developers who maintain these packages when it comes to the actual content of the packages. Package systems should not be editorializing. If the author of [insert major package here] wants to upgrade a version that replaces the whole package with a console animation of a turtle, that's his/her choice as a developer, and simply should be viewed as a "breaking change". Intervening in THOSE scenarios I view as completely out of control on the part of package ecosystems. Let people leverage their creations however they like. Your trust is supposed to be in the maintainer. If they aren't trustworthy, you shouldn't use their software in the first place. If they decide to go in a new, breaking direction, that's their decision. Caveat emptor.
These scenarios though, are starkly different from scenarios where the package maintainer's own intent is subverted by a malicious hacker / user. That's a whole other can of worms, and I agree we need better controls to protect all packages from these types of scenarios.