If I'm an open source developer who starts uploading malicious packages to a repository they aren't obliged to not delist my malicious packages. PyPI is proactively considering critical packages without 2FA protection malicious
> The package repository isn't preventing the developers from continuing to publish their packages elsewhere
You are right that the package index doesn't owe developers anything and this is in fact something I called out explicitly in the post. However I believe your point about "isn't preventing" is not quite accurate. In order to participate in dependency trees in most ecosystems you need to be on "the" index. Yes, you can sort of create dependencies to stuff off PyPI but this breaks down really quickly. Because of this PyPI has a special role to play.
This is not too dissimilar to discussions we are having about freedom of speech and similar things at the moment and I think the answers are much more nuanced and complex than it might look on the surface. If PyPI were to start putting restrictions on some people publishing or accessing packages, we had a much bigger challenge on our hand. To be clear: this discussion is not about that, but the "just move somewhere else" type of answer I do not believe is a good option to dissatisfaction with the primary index.
In the same way folks can get upset over being required to use 2fa, the package index maintainers likely get upset every time that they lose hours of their life due to someone not using 2fa.
Despite much of this being critical infrastructure, I would be surprised if most people who run the index are doing so as part of their day job instead of volunteering. This is why I always try to show a lot of grace when people make decisions that I don't understand, because they may be facing situations I don't understand.
re requiring 2FA across the platform, I wouldn't be surprised if 2FA requirements eventually expand to everyone
Maybe this could've been opt-in by having a way for projects to require their dependencies be 2FA all the way down. Since the current policy has a bit of a hole: if you're a critical package, are you allowed to depend on a non-critical package? Are you no longer able to add non-critical dependencies?
And it's ridiculous for them to do so. How can they verify that the 2FA program is not just being run in a virtual machine? At the end of the day it's the maintainer that decides the security of the package.
Ultimately, PyPI cannot prevent TOTP secret misuse. But we expect the overwhelming majority of users to not misuse TOTP, and a corresponding security advantage therefrom.
Content hosts have hosting rules. Don't like updated rules? Move to another network or self host. You as a platform user have to weigh the pros and cons that come with that decision.
Personally I have stopped contributing to open source due to consumer expectations around free work. My passion projects are now all private and they are all mine or employers who gain from my learnings by paying me. If that's a loss to society, well society can figure out the cost-benefit analysis and get back to me with a better proposal.
Side not: upon going down this rabbit hole, I find that Facebook/Zuckerberg is their primary sponsor[0] and the fact that auth is becoming more of a thing leaves me with zero surprise
Here is my first-hand account: the money that Facebook donated to PyPI was used to pay me to implement 2FA (and a whole bunch of other things). It wasn’t used for any of the current rollout, to the best of my knowledge.
This is a very rational decision. In contrast, I think it is irrational when people keep contributing to OSS while at the same time nurturing resentment towards people who feel entitled to their help, support, or whatever else.
Currently the "critical package" categorization may offset most of the likelihood of that occurring, although I'd expect there could be problems for some projects even so.
I wonder whether PyPi considered making 2FA-at-publish-time optional and instead offering a question of 2FA-at-package-install-time.
In other words: "pip install --2fa-signed-packages-only" or similar.
It's possible they didn't, or weren't able to, because the ecosystem is already widely deployed and many package version upgrades (including transitive dependencies) occur automatically.
Roughly speaking: I like the author's suggestion (quoted below) of making the the software package ecosystem an immutable (content-addressed?) space, where policies and attestation about whether to use those packages is opt-in based on rules-based overlays. That'd be ambitious but technically feasible, I think.
"So if I were to wish for something, then that the index has no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies."
(that implies that a naive implementation of '--2fa-signed-packages-only' flag would mean 'packages that were published using tokens that were generated by a 2FA-authenticated user; possibly a subtle distinction, but maybe worth mentioning)
>THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
If you want support, availability, or timely fixes, you need to form a business relationship of some kind. Which almost certainly involves paying someone.
That has not happened here (at least in the vast, vast majority of cases), so I think they're entirely fine stopping updates / going elsewhere / removing their package, if they want. Anyone who falls apart due to that hasn't been doing due diligence. It totally sucks for them, but that doesn't mean they get to force their issues onto others.