Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial. Or you can just put your code on github. Or pastebin. Or nowhere.
As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems.
Sorry but I just do not care at all about this "burden" that you may feel because you've been asked to enable 2FA for a site that hosts your code for free.
A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced.
Ultimately,
> I think as an Open Source developer who is using the index for free, I can't demand much from it.
I feel like the article could have been this one line, and then there could have been a separate post discussing the merits of 2fa vs vet.
> As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems.
I disagree.
On the surface and a technical level cargo-vet and 2fa do different things, yes. However, the intended effect here is very similar. PyPi is asking some authors to use 2fa because they want to avoid popular packages getting compromised. Cargo-vet tries to achieve the same end result through a different method.
> A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced.
While unlikely, it does bring up the question of how much control a package index, or similar org, should be able to exert control over contributors. In theory, its their index and they are hosting your code for free so they can do as they please. On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world.
I suppose so. To me, 2FA is solving the "who manages the package" whereas vet is a solution for distributed auditing of what the package does. Ultimately their goals align in that they're both trying to prevent an attacker from manipulating the code and having that successfully deploy to users' systems.
I think they're just so wildly different in every way that it's hard to say they're solving the same problem unless you zoom way out.
The reality is, however, that the `vet` approach has never been shown to work at scale, and 2FA has. 2FA has decades of implementation work, threat modeling, etc. `vet` is a one off tool for Rust and no integration into the wider ecosystem.
I would love to see a `vet`-like tool for PyPI, I would love that, but saying "we could have used vet" is really glossing over a lot of practical issues.
> . On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world.
Yeah, sure. At the same time, why is it that open source maintainers get to say "I have literally 0 ethical responsibility to do anything ever"? That's the status quo - maintainers who distribute their code through these repositories owe you nothing. We accept that. But we don't hold the same thing true for the package repository? They suddenly owe the maintainers something?
More directly, maintainers have their goals, repos have their goals, users have their goals. They'll align where they can, but no one is beholden to anyone else, and we can't really change that.
One obvious difference is that 2FA prevents the attacker from taking ownership of the package and distributing a malicious version, vet theoretically prevents installation of the malicious version. The vet approach comes into play much later.
Also, as I mentioned before, there's no evidence whatsoever that the 'vet' approach even works, let alone scales.
I didn't say they're the same, or even practically equally effective at all cases, I said one is a superset of the other's threat model.
2FA covers cases where the attacker is not supposed to be authorized to distribute the package. But vet covers all cases where the code isn't doing what it's supposed to do; that includes cases where the attacker wasn't authorized to distribute it, but also cases where the attacker was correctly authorized, or the authorized person simply made a mistake.
An actual disjoint model is something like Go's TOFU proxy, which makes no claims about who was authorized to do what or what the code should be doing, only that it's the same for everyone.
I don't see either side demanding anything. Each is providing conditionally free contributions. The article is one side explaining what they see as a downside to the other's conditions.
Well, to be fair, they did unilaterally assign their notion of criticality to this package and based on that unilaterally imposed conditions that the maintainer did not agree to up front and cannot negotiate.
One option would be for the maintainer to never release an update for their package on PyPI going forward.
The author also doesn't demand anything of anyone.
Users, on the other hand, demand Python software they want to use be available via PyPI. Since both PyPI and software authors are usually trying to act in some users' interest, there should be space for actual discussion and not this zoomer libertarian "nobody owes anyone anything" nonsense.
I think 2FA, if it mandates SMS use, is a burden for certain package types. Imagine a package that helps you write software that bypasses the Great Firewall. There is occasionally value in anonymously authored software, and cell phones to degrees that vary by country reveal your identity and at the very least give a central authority knowledge about your location.
Hope these comments don’t make you go crazy. It’s always fun and frustrating to see an area you are extremely familiar with being discussed by those unfamiliar.
I have a lot of sympathy for some of the frustration being expressed here: I do a lot of open source maintenance, and any amount of change to my workflows drives me up the wall!
That being said: the PyPI maintainers are also in this community, also doing largely thankless work to keep one of the world’s biggest package indices healthy (and secure). Their motives are good, and (IMO) the rollout here walks the right line between imposition and changes that are necessary to match the prevailing winds in supply chain security.
Thanks for the kind words. Just to clarify (and avoid stolen valor): I worked on the 2FA implementation, but not the current critical project scheme or free key giveaway. That was all done by PyPI’s maintainers (I’m just a contributor), and they’re absolutely incredible and tireless in their commitment.
In that scenario though I think there are reasons why one might avoid package repositories such as pypi. For instance, say a censorship avoidance package is popular on pypi - what happens when whatever authority comes knocking?
I would think that it would be more secure to provide anonymized distribution as well. Of course, that means that you lose some convenience and reach, but that’s a common trade off in scenarios that have elevated security needs.
As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems.
Sorry but I just do not care at all about this "burden" that you may feel because you've been asked to enable 2FA for a site that hosts your code for free.
A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced.
Ultimately,
> I think as an Open Source developer who is using the index for free, I can't demand much from it.
I feel like the article could have been this one line, and then there could have been a separate post discussing the merits of 2fa vs vet.