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.
The index thinks that a widely- adopted package looks like a tempting target for hackers to inject malware. They need to help avoid that, for ethical, legal, and business reasons. Signing the release sounds perfectly reasonable too.
HOWEVER
I do think that a lot of the committing here is focused too much on the thing that got the author thinking (2FA), and focused too little on what the author was thinking about.
It is worth noticing that there's a potential for a package index to leverage your user base against you and start making demands. Of course you could walk away from pypy, or npm, but that's almost like suggesting you walk away from the Google Play store if you developed android apps. I like this article as something to keep in the back of your mind when you look at the future of package publishing.
How likely will this repo/index be to demand money from me some day when my user base gets large enough? Can I be delisted because of a new content policy?
Exactly, I'm in the same boat as the author and you, where the 2FA is just a mild inconvenience (I travel a lot, no fixed sms, have lost too many yubikeys). However indexes forcing authors to use 2FA has open my eyes to how much control they have; if they required tomorrow to identify with a national ID, or pay $10/year for the top 1% of authors they could easily do so (e.g. any action not "too" drastic to have a massive backlash, meaning it's draconian but only for very few). This could go virtually in any direction and they have a massive amount power, and that feels very scary indeed.
I've invested 10s of thousands of hours in writing open source, which I'm very happy to share with the world, and while I have multiple backups being banned or unable to use npm would def be a tragedy for me.
The index didn’t force the devs to do anything. The developer can just stop uploading packages.
Years ago software was just distributed by the developers themselves on their own websites, or by Usenet, or even by floppy disks.
It may well be that the developer wants to be on the index and is willing to pay. In that case, OK. Maintaining an index is not free, so if the indexer needs to charge somebody, it could be users, or it could be developers.
Well it's not years ago, in general most languages have been centralized around a single large index, which gives many advantages but also some disadvantages like seen here. This has been great so far since they've been benevolent, but in cases like npm (which I'm most familiar with) the non-profit Node Foundation joined the private company npm inc. giving it basically exclusive rights. Previous node and npm inc developers have tried to make alternatives, but unfortunately the reality is if you want to publish a JS package today and want anyone to use it, you should use npm.
> Maintaining an index is not free
No, it's indeed probably very profitable when npm was sold to Microsoft, since the npm owners fought tooth and nail before to keep it private and not part of the Node Foundation.
I think it would be perfectly reasonable for these platforms to start demanding money. As a consumer and a producer of packages they provide a huge amount of value. Yes I could run my own but it's deeply inconvenient in many ways, that's part of where that value comes from.
PyPI is so easy to self host it's almost a joke. You can run a single python simple http server (one command) and use specific file system layout and you have a compatible pypi.
If there is such a significant mismatch in what pypi is going for vs contributors, people will migrate to another solution.
there's a big gap between "meh it's okay" and "pypi really goes above and beyond to serve the package developers and the users too".
it's strange (unexpected? totally expected? sad?) that the for profit npm (which started out as the butt of every supply chain joke) seems the most dev friendly.
eg. npm has namespaces (and neither pypi nor rust's crates.io does. and the Rust dev experience is usually considered sublime, and the whole decision making in Rust land is [was?] very dev-driven)
It does seem reasonable that if someone publishes an open source package to an index for distribution, they are accepting that the index may place some constraints on them once their package hits critical mass. So in this case once the authors package received greater than X downloads, they were required to log in to the index with 2FA in order to continue to publish releases. From how I read the article the author was okay with all of this and even reasoned through the requirements.
I think the next key point is subtle: at what point does a package become 'critical' enough that an index might feel empowered to take it over in the name of 'the ecosystem' or 'the community'?
To my mind the question comes down to: who are the people running the index and what are their economic interests? How do I know I can trust the index will not suddenly impose draconian rules or abscond with all the assets wholesale?
Considering where we are in 2022 this is worth considering for more than five minutes. Traditional supply chains are being disrupted and there is an incredible geopolitical realignment taking place across the globe at the moment. Black swan events in a way are the new normal and we cannot take things we used to know for granted (e.g., how freenode changed so quickly and of course how the pandemic caused the world to shift on a dime).
> How do I know I can trust the index will not suddenly impose draconian rules or abscond with all the assets wholesale?
You can’t. Look at what happened to freenode where the admins sold rights to the server to a private buyer who immediately implemented strict controls on how channels operated.
The same trust problem that PyPI are trying to solve with maintainers of critical packages applies to the index itself.
I understand the author’s concern here, but I want to point out a couple of things (both specific to PyPI and more general):
* Package indices have always had opinions about their users’ contributions. Most indices have revocation/yanking policies that are applied to cases of namesquatting, obviously malicious packages (even if the author claims that it’s intended to be a demo), and so forth.
* PyPI has worked exceptionally hard (in my opinion) to minimize the potential disruption here: maintainers are being given free physical security keys, and those who can’t receive them will still be able to use TOTP. The rollout here has also not been enabled, and will not be for some time (to give maintainers plenty of time to enable 2FA on their own schedules); this is merely the announcement for the plan.
* Enabling 2FA on PyPI controls access to PyPI’s web interface, not publishing workflows. In other words: if you’re a maintainer of a critical project, enabling 2FA will not “gate” the releases you publish via CI. All of that will continue to work as it has before.
For publishing workflows, you should be using an API token (which only allows access to the upload endpoint and nothing else; critically, you can’t modify your account via an API token). This is consistent with how most other services handle both user and machine interaction, and (IMO) strikes the right balance between security and practicality.
I received this email and did not appreciate it too much also.
It is like:
"Congratulations, you are designated as critical, as one of the top downloaded package"
So you think, awesome, what is my prize?
"You won the right to have more restrictions on your account"
I think that it would be ok for the index to show which package are 'safer' but indeed not do it like that.
In the best world, I would imagine something like that:
Your package is tagged as not 2fa safe. Users can pledge a donation to the maintainer to motivate him to use or keep using 2fa. That he can't get without using 2fa. Something like that so the maintainer does not have all the burden that only benefit to 'free' users.
I think I agree with the author that this is potentially a slippery slope. 2FA alone is a great idea, passwords are one of the worst inventions in human history, but it only protects against one supply chain attack -- having your password guessed. What happens when you say "fuck everything" and upload intentionally broken code? We're going to need a mental health assessment. What happens if you're in debt and someone pays you to upload broken code? We're going to need a background check. What happens if malware modifies the code you upload? We're going to need to run this antivirus software that sends all the files on your workstation to our Corporate Overlords. I mean, if you don't agree with all of that, are you really SERIOUS about being a software engineer in your spare time?
The intersection of hobbyists and corporations is a mess. At the end of the day, most people writing open-source software just wanted to scratch an itch. They could be doing anything they want in their free time, and their top choice is probably not to support some Fortune 500's infosec OKRs. It's important to balance modern security requirements with the fact that there is a human being on the other end who is not your employee.
This is a really interesting field of discussion, because there are such strong arguments in both directions. I don't think there's a single right answer here.
I personally come down more on the side of "registries should have policies limiting the damage that their participants can cause", but I absolutely respect the arguments that "volunteers working for free should not have additional restrictions placed on how they do their work".
As someone who likes 2FA, I definitely see the author's point here. It seems kind of unfair to say "a lot of other people now use the thing you've been uploading here, so now here's a bunch of new rules you have to follow".
However, just as open source developers don't owe downstream, package repositories don't owe open source developers. The package repository isn't preventing the developers from continuing to publish their packages elsewhere
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.
I suspect your discounting the amount of effort it takes pypi index maintainers to respond to compromised packages.
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.
Overall I agree that the matter is more nuanced than my original comment would indicate
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?
>PyPI is proactively considering critical packages without 2FA protection malicious
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.
You appear to have a fundamental misunderstanding of the 2FA in this case. TOTP-based 2FA is available for PyPI, for which any number of FOSS freely-runnable clients are available. See also https://pypi.org/help/#totp
I think GP is actually saying that there's no way to prove that users aren't storing their TOTP secrets in a way that defeats the purpose of 2FA, such as right next to their passwords in cleartext.
This is why we encourage WebAuthn by default (and why PyPI is giving out free security keys): it’s much more misuse-resistant.
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.
We've seen it with social media and content moderation. It's just a little ahead of the game because more people means entities come to the conclusion faster.
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
Facebook is not PyPI’s “primary sponsor.” To the extent that any company could legitimately claim that, it would be the one that provides PyPI’s CDN for free.
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.
> 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.
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.
In particular, if package indexes start introducing additional requirements for developers, as mentioned in the article, then I do worry that it could risk moving an unreasonable level of burden onto developers (who may initiate or develop code purely for their own enjoyment).
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."
A correction/clarification since writing the parent comment: publication of packages requires an authentication token, and does not require an interactive 2FA challenge. Generating a suitable token for package publication, however, does.
(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)
Particularly when using a license that explicitly says "you're on your own":
>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.
I also got one of these emails as I created a package that apparently gets millions of installs these days. Personally I have zero issue with PyPi putting more restrictions on these packages, I wish they would do more. As a maintainer it can help me be less likely to screw up.
Ultimately I feel no obligation to contribute to open source or continue to maintain this software. (In fact others have taken over a lot of it for years.) It's a thing I chose to do, I bare the responsibility for those actions. If it gets too much work for someone we should have no bad feeling towards them for walking away.
However maintainers get a lot of bullshit but PyPi are really not contributing to that. There is a slippery slope argument here that I think is just nonsense and in particular I trust people like dstufft and the rest of the team to do their best to avoid contributing to it.
So PyPi team, thanks for this, please feel free to do more.
Yes the package repos have a ton of power. We have a kind of social contract with them to act responsibly so far but all of these platforms are built on a giant pile of donations and free labour. If that contract is violated we'll start finding new solutions. Up until that point I'm happy to let the people with the sweat equity do what they think is right.
I agree with the author that the request is unwarranted. As far as I can tell, most licenses typically have a clause that waive any damages caused by the software along the lines of 'THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER "AS IS"...', so there is absolutely no moral obligation on behalf of the author. e.g:
Absolutely agree that PyPI, seeing that it benefits from the contributions of unpaid developers, doesn't really have a moral right to exert this kind of control over developers. Basically, corporations are free-riding on the unpaid work of developers, and now they have decided that some packages are "critical" and require more unpaid attention. Here, have a Google 2fa key, the proprietary firmware will surely be convenient.
I also kind of see the point others are making regarding the OP's presumed entitlement; nobody is forcing them to publish on PyPI. Yet, PyPI is the go-to distribution channel for Python, so if you want to contribute anything, it is reasonable that you do it through that channel. It's the similar kind of network effect that happens with 'social' networks.
If the go-to distribution channel is run rampant with supply chain attacks, doesn't that kill the distribution channel? Surely the philosophical argument against forcing maintainers to use 2FA is at odds with the extremely real existential threats to the longevity of the service?
There are many other problems beyond what 2fa can solve, so this discussion focused solely on 2fa is missing the forest for the trees. Specifically, one can get malware into a package via (a) publishing a malicious version of the package using stolen credentials, or (b) having the malware merged in a PR. 2fa only protects against the first case. Also, pulling in third-party dependencies into a software project without reviewing them is a terrible way to develop software, so the responsibility does not fully lie on the provider of the package (and, as I mentioned earlier, there is legally no responsibility on them anyway as per many of these free licenses.) So there are many more ways we can kill a distribution channel that 2fa cannot solve. Forcing 2fa on a select number of packages to suit the whims of corporations is still a shitty move. Though I still agree with you that, in general, more guarantees on the origin of a package is for the best.
This is a tricky one for me, and from what I can see... others too.
My initial reaction (and what I feel is common for others) was that this is overzealous -- 2FA is something everyone should already be doing.
It's somewhat like being upset that your poor hygiene came up while donating your time to the local soup kitchen. Your acts are good, but perhaps you shouldn't be handling/dispensing food.
I totally understand the fears of centralized power for these indexes. I think others (like myself) are just getting hung up on what lead to this consideration
There's something interesting with their picking and choosing of who gets policies, but in this case... it's fine in my opinion.
The most downloaded packages have the largest blast area, this might stop some explosions - so it's worth it [if you care about your users].
The argument the author makes seems really nonsensical. It really comes off as "i would like to have my cake and eat it too".
It's true it's not the fault of the author that a thing became popular.
So what?
If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism.
Nobody is forcing you.
That will cause you to have no responsibility.
It will likely cause your adoption to be lower, but you just argued that it isn't your fault adoption is so high, so presumably you don't care.
Otherwise you are arguing that you owe nobody anything, because it's not your fault, but the distribution mechanisms owe you something - free distribution without responsibility!
In reality, most people care a lot and want their project to be popular, so making arguments that "it's not the authors fault it is popular" are generally pretty disingenuous.
Whether that is the case here, who knows, but it is pretty hard to be sympathetic to an argument that plays both sides, and claims you owe nobody anything while the distribution mechanisms owe you something.
> If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism.
The rules in a way are changing with the threshold of "criticality". In a way what you are proposing is suggesting to developers to unpublish if they do not want to deal with the complexity of that. This is exactly what happened yesterday accidentally (https://news.ycombinator.com/item?id=32026624). From the responses I have witnessed to that incident I do not believe this a path anyone should take.
> claims you owe nobody anything while the distribution mechanisms owe you something
The post explicitly states that the distribution mechanism doesn't owe developers anything.
I think a lot of people are hung up on the fact that 2FA was your example because 2FA is widely regarded as a good idea.
My takeaway from your article is: if I create an open source project and it becomes popular, I’ll have a bunch of responsibilities I didn’t necessarily sign up for. Those responsibilities will probably include things that I don’t know how to do or don’t want to do as an IC.
I suppose some people are looking for that when they work on open source, but I am personally almost never looking for more responsibility. I have enough already, thank you.
I wonder how many more people would contribute to open source projects if they knew they wouldn’t have to worry about project drama or being guilted into taking on more responsibility? I think it’s a very real (and probably measurable) chilling effect.
EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?
The amount of work required to maintain a very popular package is obviously higher, even without taking into account any distribution part. From your message it sounds like you expect same amount of work. Besides, the extra work from this side would pale to the extra amount of work needed to maintain just due to increase of users.
Yes, that's the status-quo. But OP is arguing, rightfully so, that we don't want to put additional responsibilities to already hand-full maintainers. If anything, we want to reduce that to make open source community more sustainable. We've seen too much that maintainers burnt out, shutdown repos, or beg for money to just keep the light on. Once they turned the project into commercial endeavor to "spread" the burden, then they have the dilemma of "open-core" dual license.
There must be a way to make the extra work minimal for maintainers even if their works are popular. For example, in the days people use apt / yum for distribution, both vetting and packaging are the responsibilities of the packagers, not the maintainers. (Not saying that's good, but just an alternative perspective, there is a reason why language-specific package registry wins today).
> EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?
I'm pretty sure {your favorite popular basketball player}'s career prospects would not have been impacted by an NBA requirement to "spend 10 seconds sitting on the bench to warm it every day before playing". Doubly so if there was a reasonable argument that it would somehow make the stadium safer for their fans.
Volunteering is all about taking responsibility. If you contribute regularly to a project with many users, you can't avoid the responsibility. If you only want to express yourself by writing code without the burden of responsibility, you should contribute to something else.
One thing I've learned from various volunteer projects and organizations is that good volunteer administrators are rare. Finding good people for the creative parts of the project is not particularly difficult, because creative work is inherently satisfying. Administrators are another story. Many try the job and quit, because they don't enjoy it enough to do it in their free time. Others are not suitable for the role. Some are good and motivated administrators, but they drive other volunteers away by trying to manage them. And then there are the rare ones who can be administrators and enjoy it without ruining the project for everyone else. If you manage to find one, the last thing you want to do is increasing their burden.
As far as I understand, PyPI is largely a volunteer project. It works only because some people find running that kind of bureaucracy satisfying. It's their project, and they can run it any way they want. If their burden gets too heavy, they may quit, and then the project may fail. That would probably be a bigger issue than some open source contributors not liking how PyPI is run.
Honestly I don't think this is a hill you want to die on. "The greater your influence, the greater your responsibilities" is something society generally agrees is reasonable in most domains, and this is just a manifestation of that principle in the case of OSS and supply-chain integrity. The principle is pretty universal in modern society though. If you see an unreasonable responsibility being placed on you, for sure, complain about that. But if you don't think the responsibility itself (2FA in this case) is unreasonable, and in fact think it should be mandated on everyone, "it's a slippery slope!" and "it's not fair!" are not going to be compelling counterarguments for most people. It goes against what people expect in society.
When we write software as part of a job, we have all kinds of staff who support the project —- project managers, product managers, QA, marketing and sales, security etc etc.
It really seems that, for open source projects, the author is expected to be responsible for everything.
I think it would be a great benefit to all of us if people who wanted to open up code but didn’t want to add responsibility to their own world felt welcome to do so. I think it’s a problem worth solving.
"I think it would be a great benefit to all of us if people who wanted to open up code but didn’t want to add responsibility to their own world felt welcome to do so. I think it’s a problem worth solving."
I think i would strongly disagree with this view - this is similar to arguing that people should just be able to release plans for nuclear weapons (or take your pick of less extreme examples) without adding responsibility to themselves, etc.
There's no obvious reason they should be able to, or that it is a net benefit to society. It's one of those things that people often think "sounds good", but isn't that great in practice, ever.
In fact, most of the problem that exists today in OSS security, support, etc is precisely because of people opening up code without trying to add any responsibility to themselves. At the same time, OSS has produced 100 of everything, so it's really hard to believe arguments that "if we didn't let this happen, things would not progress" and the like. I don't believe we would have been worse in terms of progress, etc, if we instead had 10 of everything, with the people more willing to take responsibility.
More practically, society has always believed in balance in every similar sort of thing, so it's not obvious to me why the extreme of "everyone can release anything without any responsibility" is ideal for anyone.
> It really seems that, for open source projects, the author is expected to be responsible for everything.
If you wrote "for underfunded projects" I would agree with you. It's a pretty universal fact of life regardless of the nature of the source.
> I think it’s a problem worth solving.
Definitely, I don't think anyone is against a solution to this problem. The question is what we can expect before the envisioned solution is finally created by someone and provided to us.
What’s interesting is that we don’t really have this kind of structure in place elsewhere to my knowledge, outside of open source software. There’s a limit to how much legal liability you can shed, and even after that social liability is much more fickle.
It’s the free (no payment) part that makes the difference and outside of the Open Source movement many things are not provided free of charge because of the associated costs.
Similar things happen for research papers or generally scientific content though. You won’t be successful in suing an author of a study for incorrect content either.
Fundamentally I agree with you. But I also think it easy to get the idea that "no responsibility" is a prevailing view. Or at least that it has to be. There are plenty of people who want to do their best. I would certainly considered the author's software involvement to be part of that. It is just hard to do. And increasing hard not only because of software but society at large (like job and housing markets). So the problem exists regardless of various positions on the issue.
Or put another way. If we want open source developers who favor responsibility we have to make it easy for those developers. Otherwise we only end up with people who are fine with throwing things over the wall.
2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects"
As a user installing from a registry, you are trusting both the publisher AND the distributor.
Consider an attack where the distributor is adding malicious code to 1% of installs. The publisher is not involved in the process and (unless code signing is involved) has no influence.
But if code signing is involved, why is 2FA even needed? The signatures themselves should be sufficient proof.
So 2FA overall is a solution in the lens that the distributor intermediates the relationship. This need not happen. People can chuck tarballs and post signatures, establishing more direct trust compared to the indirect solution.
That's not even the point of the blog post to begin debating it here. If the the author believes that then he can write a blog post about how 2FA is bad. That's not what we have here though. In fact, he instead says "it's a sensible thing" and his complaint is that it's a slippery slope: "More importantly though is what could come next. There is a hypothetical future where the rules tighten."
> 2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects"
This is not what 2FA asserts in the context of PyPI. It’s used solely for logins to the web frontend, which is where users can manage their projects and the permissions associated with those projects. The idea is to make account takeover more difficult, since that’s (frequently) the first step in malicious package takeover. Assuming that you’re using API tokens to publish to PyPI (which you absolutely should be), having 2FA enabled on your account will not affect any ordinary publishing workflows.
We have separate plans to improve PyPI’s support for code signing.
They solve different problems. Given a signed package I can say "this is signed by that key". I can't say how that key was registered, or who registered it, etc. 2FA would be where that key registration actually happens.
That doesn't seem to apply to companies -- they make billions from open source and give back little, or nothing, to the majority of the authous and packages whose work they build on.
Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".
2FA, whether TOTP or physical, comes with a per-user support burden for any organization that enforces it, because there must be a human-in-the-loop mechanism to handle "my 2FA devices were all destroyed/stolen, and others depend on me having access to my account." PyPI isn't exempt from this, despite mitigating with multiple 2FA devices, and says as much in the announcement https://pypi.org/security-key-giveaway/ -
> Without multiple 2FA options, effect of losing a 2FA method results in the need to fully recover an account, which is burdensome and time-consuming both for maintainers and PyPI administrators. Enabling multiple 2FA methods reduces the potential disruption if one is lost.
So there's a huge practical difference to PyPI of enforcing 2FA for all vs. enforcing for <1% of projects. I don't envy their position, and it's a reasonable compromise IMO.
That said, it's absurd that PyPI didn't make more clear in the announcement linked above that TOTP apps are allowed. There's literally not an FAQ about the most important FAQ. They very well could have avoided the reaction from OP, and this entire debacle, with more thoughtful messaging.
I think "unpublishing" packages is generally not something that should be done, except in the case of malware and maybe some other cases, and I believe that e.g. NPM already went through an iteration of this issue, which is why they have an explicit policy around it: https://docs.npmjs.com/policies/unpublish
But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes.
The fact that a package got yanked from the registry because of this is an unfortunate combination of a) PyPI allowing it (they shouldn't, and learn from NPM's mistakes), and b) the maintainer being really unreasonable in the face of a perfectly reasonable request.
> But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes.
That seems worse to me for quite a few cases that go towards actual burden beyond 2FA. That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. There is a reason why I have a "No Warrenty" clause in the licenses of my Open Source work. I have created it for others to enjoy it, but I reserve the rights to not be burdened by my users for the unpaid labor.
Sure, but then who does the work? No one is an answer but not much of a solution since the problem still exists. Index or package maintainers could do the work but would often also be unpaid and burdened even more. An organization could do the work but most packages don't reach the level where they would get adopted.
If being unpaid is the problem then the most obvious solution is to charge for the index, possibly only for commercial use, like a streaming service. Use some for the index and give the rest to the projects who does the work. As far as I know it wouldn't be against open source as people think non-commercial licenses are. But it would still be hard to do for various reasons. Some legitimate and some not.
> That implies the index will take away someone's permission over their creation as a result of too many other people also started using it.
The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog.
The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.
Here in the US folks tend to have some amount of burden on their creations, tools they use, etc. Just because you put out a sign that says “Not My Problem” doesn’t make it so.
Great example is these big gravel trucks hauling rocks to job sites, they’ll rain stones on the roadway and the cars and sometimes pedestrians because the workers are sometimes too careless to pull down the tarp to secure their load. They’ll put up a sign saying “DRIVER NOT RESPONSIBLE FOR DAMAGE” but the problem is they 100% are both legally and morally responsible.
We also have some rules around nuisance, enticement, etc. For instance, if I have a pool and a kid jumps my meager fence and drowns I might we’ll still be responsible, at least legally, because I put up an enticing thing but failed to consider how idiots might misuse it.
To me, the pool one starts to get at or near “South of Sanity” but that’s from where this mentality applies.
Often you’ll get some Node project some cool tech person shits out, pimps out to social media , then abandons when the real work comes out. Folks will pick it up early on as traction builds, then be stuck with abandonware when the author gets a new job or chases a different shiny ball. I would argue you at least owe a caveat in the README about your level of commitment to the project, a bit beyond a mere “not my problem” license line.
Wow. This attitude is exactly why I don’t post software anymore.
I’m not delusional; I know that the world might be better off without my creations littering it. But if I were an attorney advising $Bigcorp, messages just like this one are why I would advise against posting any free software unless there is a business case for how the benefit outweighs the risk.
And a disclaimer does not eliminate risk, not even the heightened disclaimer you suggest (why isn’t the disclaimer in the license enough?) The instant I have to defend a lawsuit, I’ve lost. It doesn’t matter if the suit is meritless and I “win.” Then instant someone sues me, the only winner is my lawyer.
I guess this was all inevitable when people started relying on free software. They somehow think people who have given them something for free owe them something. I guess this works fine when the giver is $Bigcorp doing it for profit-seeking reasons. But this attitude is going to strangle the old small-time hobbyists who really were just scratching an itch.
Now I know why some software is posted under pseudonyms.
You are absolutely right here. If anything the excluding of implied warranty works better in the US than many other countries for Open Source as typically a price is required for implied warranties to exist but even there are limitations.
I also tend to agree that there is a certain level of added burden that comes with popularity that you cannot get rid of. This starts from the basic fact that I noticed a few years back of becoming a target of social engineering.
I do however think for as long as we believe Open Source is a good thing and there is limited ways for developers to receive monetary compensation for their work, we should be quite careful here. Enrolling people into things purely based on the popularity of their creation without compensation to me feels problematic.
I think it would be ideal if the increase in responsibility was accompanied by some actual reward, so the “congratulations” would be more genuine. I don’t know what kind of reward would make sense - money makes sense, but who’s money? Maybe you get a voice in the development and direction of the language and ecosystem? That would also constitute more responsibility but it might feel less burdensome and give you a seat at the table for the next such decision.
> You can always publish your creation on your website or wherever.
What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code).
No, the issue yesterday is that people had to go in manually to fix their CI builds, etc. That's simply not necessary if you don't update the version and yanking is disallowed (which it should be).
After that, if people want to at some point update to a newer version of the package, yes, they will have to adjust.
Hrm, fair point. Although migrating 'backwards-compatibly' like that could leave a lot of people in the cold if-and-when a security update for the package is released (and we're talking about critical packages here, at least for now).
How about you 1) leave old versions in place on the package index, 2) declare that you will not be providing further updates to the package through the index because of this issue, 3) go publish your stuff on your website or an alternate package index?
> They could collect the source and vet the updates all kinds of other ways than demanding the author jump through hoops for them, for free.
At minimum it's completely unproven that that would be practical, whereas 2FA is trivial and has been widely deployed for decades.
But if you feel strongly about this feel free to make a formal proposal. There are some nascent projects exploring this area that you could draw inspiration from and I'd certainly welcome tooling in that area.
What a weird leap. Now not only the author of some software has to jump through someone else's hoops, I a total bystander also has to? It does not require "feel strongly" to observe the invalidity of some argument.
Rather, if you feel so strongly that something should be done, like vet that software, you could do it.
Is the whole point of this not to ensure that someone can't use your identity to produce a compromised package?
When I download someone else's code its my job to make sure the code I run isn't riddled with spyware. Hence why I design my projects to rely minimally on external dependencies.
Why should this burden be placed on the developer and not the user?
If I buy a chainsaw and cut my arm off, is this the fault of the chainsaw manufacturer?
You do know that bladed machinery is made with more and more safety features right? No one actually thinks "oh fuck em if they lose an arm". It just isn't a good comparison, nor a good solution.
This kind of reply is frustrating. Someone wrote a nice article explaining how it may not be desirable for package indexes to force the authors of packages to put on even more work to get their free work published, work that they didn't have to do before... and the best answer you can come up with "that's nonsensical"?
Here's what is nonsensical: to call the author's argument "i would like to have my cake and eat it too" because the author does not ask to eat any cake... they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... to call this argument nonsensical is offensive to the author and to those who read the argument and actually understand it.
> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it...
Yes, the "having the cake" would be the ability to publish code to pypi and the "eating it too" would be the abdication of responsibility to abide pypi policy.
> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it
PyPi is free and not the only way to distribute your software. You're welcome to self host. PyPi, in order to be successful as a package repository, needs to serve both authors AND users. If you don't want to abide by the new policy? You don't need to use PyPi, and your account is presumably locked. Nothing is taken away from you except your ability to continue to use a free service for free without abiding by their security policies.
This is as nonsensical as being upset that PyPi is enforcing minimum password length or requiring HTTPS. They're not making money from this, they're obviously not doing it maliciously. The motive here is to stem a very serious problem with package management (across all of software) in a really mundane, minimal effort way.
Specifically when you say "the burden should be on the users who care about it," those users are YOUR users. They turn to your PyPi identity as a source of trust for the packages they download. If there's a new version published under YOUR profile, it's not possible to know whether that package came from you or not unless YOU do more work (reliably publishing about it elsewhere). This problem can't be put on the users of the software because there's no reasonable way for them to actually accomplish what you're describing. To say that the author here should not have any responsibility ignores the core premise of what PyPi does.
Frankly, putting the burden on the user would be blocking access to these packages unless the user explicitly opted in with messaging like "Flask is owned by an account which has no 2fa enabled. This could result in a supply chain attack in the future. Are you sure you wish to install it?" I think we can all agree this isn't the right way to solve the problem.
Personally I am not outraged by the fact that Python’s most popular package authors must go through the “burden” of authenticating their accounts properly.
Well, the author was happily using that distribution mechanism and built a community of users whose production systems are now locked into it. Then they rules changed unilaterally, effectively holding access to that community hostage. They most certainly are forcing the author to do something!
Sure the author had a choice to not use PyPi when they initially published a package. But doing so NOW, yanking the project and publishing elsewhere, would directly cause massive amounts of problems that would need to be solved. Who's going to do that labor? The author. There's no reasonable interpretation of this situation that doesn't involve the author being forced to do something.
Don't agree with your interpretation of what the original author is trying to convey.
It's not about the rules of the package distribution channel has. It's about the fact that they have different rules for different levels of popularity.
If everyone needed to do 2FA fine. Don't want to do it? Guess you'll distribute your code another way.
But... You can use it and we're going to gladly take your free work and host it and in the process benefit from it (look! It's so simple publishing stuff! Use us) until the liability of hosting you becomes greater than the benefit of hosting you. At that point we need to pull out the adult rulebook and teach you how to properly do things.
So to me it sounds like the distribution channels want to have their cake and eat it too while passing the work to the developers,ie the people that made the distribution channels successful in the first place.
The index wants something for their own reasons, but for some reason considers it reasonable to demand the author do something they want instead of doing the thing they want themselves.
The author provides various ideas for how they could get what they want by doing it themselves or by organizing volunteers who choose to work on that.
It's like demanding a better man-page than the author supplied, instead of writing one or facilitating someone else who may be willing to work on documentation.
If you walk into my house and I ask you to take off your shoes, you can turn around and walk away. I am well within reason to make that demand - it's my house.
OK, I'll skip the obvious analogy. PyPI is a free, open source service. It hosts packages for distribution. When you go to PyPI you say "Hi, I would like to distribute software, can you do this?" and they say "Yes, you can do this for free. There's some terms of use, and we require 2FA."
You can say "Great, I accept all of that, thanks for providing distribution of my code for no monetary cost to me" or you can say "Ah, ok, thanks anyways but I would prefer not to accept that".
The more correct analogy of what it looks like in a few months is PyPI coming back to you after a while saying “this package we are hosting for free you can only update or delete if you now follow these new terms if use. If you don’t agree we take away your access but retain the package.”
You can't say that's more correct. That's a prediction about the future that's based on nothing, as far as I can tell. Does PyPI have a history of increasing, unwelcome restrictions?
I mean, of course you have to continuously accept terms of use changes as you publish to them. That is the same as anything else. To tack on a bit of additional conversation,
"Hi, I previously published v 0.1, I would now like to publish v 0.2"
"OK, cool, we have a new EULA if you want to publish 0.2"
"Great, no problem, signed and now I'll publish" / "Ah, I don't like those new terms, I'll publish elsewhere or not publish at all"
> You can't say that's more correct. That's a prediction about the future that's based on nothing, as far as I can tell.
The statement I made is based on what is currently communicated. The "terms" is purely "you need to use 2FA" (which just to be clear I already said I have no quarrels with). I cannot judge what will be the future requirements will be for critical packages. Donald Stufft from PyPI on Twitter said that he could imagine requiring signed releases (https://twitter.com/dstufft/status/1545503252871004161).
> I don't get the complication here.
Maybe there is none, maybe there is. The consequence however undoubtedly is that if you do not accept the terms you lose access to your package on PyPI.
> Maybe there is none, maybe there is. The consequence however undoubtedly is that if you do not accept the terms you lose access to your package on PyPI.
Right but I just don't get why this is notable or why anyone would ever be surprised by this, or why this would ever be controversial. I just can not wrap my head around this being framed as a complex issue when it seems so very straightforward.
It is indeed so very straighforward and not a complex issue, which begs the question why you might not be able to wrap your head around it. I call volition.
Federated / self-service responsibilities are the only way things like this ever scale. In your example, it makes sense the index wants to push the responsibility out broadly, there’s no way the index can develop the breadth and depth of expertise necessary to write high quality man pages for every package - they’re too busy using their limited resources on maintaining the index (their “vertical”).
So what? Too bad? No one else's problem? The reasons they want things vetted and attested was never contested. The fact it's a lot of work, is a given. And neither of those things explain why the author has to do it, necessarily. Maybe it's natural, maybe the author of a thing is generally the best positioned to attest and support their own output, but so what?
If they find the software valuable enough that it matters that it's verified and certified, and the supplier doesn't feel like doing it, they could do it themselves or arrange for others to to do it or delist the filthy uncertified package or just tag it as not certified. There are all kinds of options besides demanding a volunteer do something they didn't aldeady feel like doing voluntarily.
I don't get why everyone confuses the obligations here. Just because pypy wants something, no matter how understandable the reasons, doesn't change the fact that it's pypy who wants it, for their own reasons.
The author derives no value from it (not neccessarily, they may choose to value the credit and exposure of their work appearing in the index, but they also may not). Pypy derives value from it, and all of the users derive value from it.
The obligation for supplying that extra frosting they want on the cake lies with those who want it.
I agree it's nonsense. The argument appears to dodge 2FA itself and the benefits to ecosystem by instead focusing on fairness, which is subjective at best.
It's not "fair" that the author has to accept the burden of 2FA, because they created a package that turned out to be critical through no fault of their own.
It would seemingly satisfy the author's "fairness" goal if everyone had to use 2FA whether their packages are critical or not.
It's also ironically not "fair" that the volunteer maintainers of PyPI are subjected to complaints like this for their hard and valuable work to improve the security of the entire ecosystem, which has become critical infrastructure itself through no fault of their own.
I used flask a lot and love Armin, but, with all due respect, this is an overreaction. The world is on fire and pypi.org decided to throw 1 (one) bucket on it. There's no slippery slope lurking in the shadows, "The Index" is not some mythical beast with unknowable intent, it's mostly other overworked and underpaid open source developers. It will be fine.
That’s a lot of complaining about having to log in with 2FA. You don’t owe a package index anything and a package index doesn’t owe you anything and if either of you don’t like what the other is doing you can go your separate ways. You’ll each have your own conditions for staying together and there’s nothing wrong with that.
As an open source contributor, the world doesn’t owe you participation in an ecosystem only in the way you want it. If you don’t want to play by others rules, don’t.
Perhaps your ad blocker or something else blocked out the paragraphs of the article where OP specifically addresses this point. I will paste it below. It is quite clear this is not just about 2FA but instead about a line being drawn which makes a new, special class of package that didn't originally exist when the author started work.
> There is a hypothetical future where the rules tighten. One could imagine that an index would like to enforce cryptographic signing of newly released packages. Or the index wants to enable reclaiming of critical packages if the author does not respond or do bad things with the package. For instance a critical package being unpublished is a problem for the ecosystem. One could imagine a situation where in that case the Index maintainers take over the record of that package on the index to undo the damage. Likewise it's more than imaginable that an index of the future will require packages to enforce a minimum standard for critical packages such as a certain SLO for responding to critical incoming requests (security, trademark laws etc.).
I thought at first this was a slippery slope fallacy, but it's not exactly. The author realized the power that package indexes have and wants a different system. Even suggests an alternative!
This is a very different argument than "if they do this, next they'll do that" or "by doing this they'll have more power". People often mistake the exercising of power with its existence.
Here's an example: In 2016 a huge amount of Ethereum got hacked. So much so, the creators of Ethereum decided to fork it, unwind the transactions and call that new chain Ethereum. The original chain is Ethereum Classic.
An argument I've heard is that this was a bad move because it sets a precedent and "made the chain not really immutable". If something is immutable as long certain people don't do things they can totally do, then it's not really immutable. (Jeez I don't actually want to start a fork flamewar, just contrasting the logic. Fingers crossed).
Disappointed to see you folks get caught up on the question of 2FA and not a single mention of @mitsuhiko's discussion of solutions, such as vetting as a service. Personally I think this is a very interesting idea, separating distribution from verification, and allowing for people to set their own criteria for vetting/verifying code. It would work well and scale from hobby projects all the way up to corporate behemoths. But sure, let's get stuck talking about 2FA and how slippery slope is a fallacy as if we haven't each one of us seen this sort of thing before.
> Disappointed to see you folks get caught up on the question of 2FA and not a single mention of @mitsuhiko's discussion of solutions, such as vetting as a service.
Comparing 2FA and vet is done at the end of the article and isn't, in my opinion, overly relevant. It's more of an example of "we could have solved this at a lower burden", which I don't believe is actually true (and I'd happily discuss that), but more importantly doesn't change the actual important bit of the article, which is about the relationship between users, maintainers, and distributors.
Open Source doesn't mean free. Package repositories could require payment for premium/vetted packages. In this scenario both the OSS developer and index maintainer get paid.
All my open source projects have a “money back” guarantee. They are also free. What I mean is that I am as hands-off a maintainer as one can be.
Still, Having to use 2FA to publish on a platform doesn’t bother me too much. It’s their platform, my personal inconvenience of using 2FA is overridden by me not having to maintain the platform.
If you maintain a package within the framework of a certain project, using its tools and repositories, they get to dictate the access control and other rules.
If you don't like how they run that, then develop whatever you're developing under some alternative hosting (perhaps self-hosting). Let someone else pull from your repository and update the packages elsewhere. That someone will play by the rules: using 2FA if the package is critical or whatever. You, the upstream, do not have to; you don't have to have any interactions at all with the downstream project.
The downstream project doesn't impose rules and procedures on you in order to impose undeserved obligations upon an open source developer, but because have privileges to publish changes. It doesn't matter whether or not you're the developer of those changes.
I wonder, is 2FA mandatory for all privileged access to the index itself? To all the services it uses to run? To its code? To all its dependencies? To Python itself?
2FA is a pain in the ass and provides minimal extra security. The reason why companies employ it is because their users are incompetent and will install malware on their desktop OS, so they shift the burden of security to locked-down mobile operating systems like Android and iOS.
If an experienced user does not want to use 2FA, they will run the 2FA app in a virtual machine and automate it. You can't force them to 2FA but you can inconvenience them and tie them down to a phone number, SMS, or locked-down hardware (through remote attestation).
>Letsencrypt was a boon to the web.
Letsencrypt and the existing PKI structure just forces everyone's eggs into a single basket, Ripe for exploitation from the government.
One thing that wasn't discussed in this post was SOS [1]. While PYPI's definition may not match the SOS criteria for criticality, SOS does state "... even if your project doesn’t meet all the criteria, we still encourage you to apply and provide your own criticality justification."
Doing work to improve the OpenSSF scorecard [2] could result in the author (or others, for that matter) getting paid. It may not map one-to-one with 2FA but it might make it easier to swallow some of the requirements from PYPI. It makes sense for companies like Google to pay maintainers/curators to focus more on security.
I suspect level heads will prevail if it's discussed calmly, as for the most part it seems to be. There are legitimate concerns on both sides.
The thing that I'd be keen gauge is just how much work do people on both sides feel 2FA is here? Packaging has changed a fair bit over the years - does dealing with those changes represent more or less effort than dealing with 2FA? My gut feeling is that 2FA would be set up in a fraction of the time spent futzing about with adopting the latest packaging methods. Now obviously this isn't a completely fair equivalency - perhaps packaging is also part of the process that maintainers love (!) but for most people it feels like a necessary step rather than the aim of the game. If there's another thing to compare it with that's better, I'm all ears.
I really don't understand the "critical package" dichotomy. Why not 2FA for everyone? If it's a best security practice, just say so. Set a cutoff date after which every PyPi author needs to comply. Targeting only the authors of popular packages feels weird and arbitrary.
Like many big changes, it's often better to do small-scale testing first. That gives a chance to learn more about the failure modes before switching to a larger-scale or full changeover.
If I wanted to make the change-over, I would start with the people with a lot of experience, the ones most likely to be paid to do this extra work, and the ones most likely to be interested in supply-chain security.
That seems decently well correlated with being the most popular downloaded packages, and I can't come up with a better initial sub-population.
> Congratulations: We Now Have Opinions on Your Open Source Contributions
The fallacy here is conflating package maintenance with OSS code authoring. Write code and throw it over the wall? Okay, why not? Package maintenance is another issue. Why wouldn’t people who depend on your packages have opinions on how you maintain them?
> Maybe we can find a future for package indexes where maintainers of packages are not burdened further because the internet started depending on it. It's not the fault of the creator that their creation became popular.
Hopefully this is tongue in cheek. Or else it’s got some very Neil Peart energy.
Living in a fisheye lens
Caught in the camera eye
I have no heart to lie
I can’t pretend a stranger
Is a long-awaited friend
I’m a rockstar but I don’t want to be recognized at a 7/11 (or Tim Hortons).
There are certain impossibilities in the world, like the halting problem, and DRM: "As the author, I wish to sell my work. But I don't want anyone to copy my work, and redistribute it without my permission -- or use it in a way that I disagree with."
Such a thing is an impossible ask. No technological means can prevent this from happening -- though many have tried and failed. It always results in a repressive and totalitarian ecosystem.
I think that pypi is trying to accomplish is in this category. It results in things like the leftpad.js incident.
The goal is always some specious form of "harm reduction", trust, and safety. These can't be obtained by technological means, but they can be produced.
I do think this is a bit of a billion dollar question. The way Linux distributions mostly does it is some form of long-term support release which gets less updates but still security updates. Burdening the maintainers more than the developers. However the amount of complexity of everyone trying to do that at the same time is not only crazy but also a real limit on progress.
Still something like that could be somewhat of a solution. You don't need to use for example 2FA but then you also don't get to publish to everyone today. Then you have to do a security update which would require it.
First of all, it's the slippery slope fallacy. 2FA is not a burden and you can't get any reasonable person worked up because of it. The insinuation that this might lead to other sorts of control is pointless; this possibility has always existed.
Second of all, package indexes have a responsibility to the programming community as a whole and as such I do expect them to make some reasonable demands. This is not infringing on open-source developers' freedom, since nobody forces them to release their code on an official package index.
Not a storm in a teacup. Being forced to accept unvetted electronic devices from a 'Foundation' instead of using TOTP rings a whole lot of alarm bells.
* How do we know that these ain't fitted with GPS trackers?
* Why are maintainers forced to give up their snail mail addresses?
* How will the keys be re-issued? Who's going to pay for this?
* Oh, and there's still the silly geo-fencing issue: 'Austria, Belgium, Canada, France, Germany, Italy, Japan, Spain, Switzerland, United Kingdom, and the United States'
You are assuming that the contributors are required to use these specific devices. This is incorrect. PyPI is offering free U2F devices to a subset of the affected developers, but they are free to use their own U2F devices (or a TOTP client) instead.
> Oh, and there's still the silly geo-fencing issue
The list of countries makes this sound like an export control issue. It's a legal restriction, not a deliberate choice PyPI made.
It seemed clearly-written and thought-provoking to me; the author doesn't claim that 2FA is a burden, either.
Writing and distributing software should be straightforward so that everyone can participate. And consuming software should be safe so that people and infrastructure are protected. Finding a security model that achieves both should be the goal.
PyPi appear to have walked a reasonable line on this so far, and it's worth considering and discussing what the future could be like.
Another reasonable point here is that pypi is also offering package owners ~$75 (edit: didn't realise they were sold in 1-packs now) in modern usb-c fido2 keys if you have one that is now marked as critical.
This last decade has played host to some of the most fascinating series of debates, an almost visceral push and pull, concerning individualism vs collectivism, distribution of control vs centralization of power.
- COVID vaccine mandates
- Cryptocurrency
- Deplatforming
- Abortion
- Closed platforms beating open web
- Monopolies controlling tech
- One party governments gaining in power
Strict control over package indices is one manifestation of this. Controlling a blast radius (safety) vs unlimited, unfettered publication (freedom).
2FA is a major pain in my ass and it is the only reason why I am forced to own and use a "modern smartphone" which is essentially a corporatist surveillance device.
If more organizations just allowed me to have custodianship over my own keys like GPG for example, I could choose my own level of security by using a GPG smartcard if I wanted to.
> 2FA is a major pain in my ass and it is the only reason why I am forced to own and use a "modern smartphone" which is essentially a corporatist surveillance device.
TOTP-compliant services happily accept codes generated from non-mobile devices. 1Password even includes it (which is a unification of factors I don't personally trust, so I don't use it, but it's there if it fits your own threat model). They can also run on Android, etc. devices that literally-not-figuratively never touch the Internet, if device separation is a concern for you.
If your hangup is Duo or Okta or similar--well, there's always the choice not to work at places that necessitate them for 2FA.
> If more organizations just allowed me to have custodianship over my own keys like GPG for example, I could choose my own level of security by using a GPG smartcard if I wanted to.
Even developers don't want to touch GPG. That's why they don't and a large part of why things like Git commit signing are (IME) so rare.
I use Okta and it supports webauthn/fido just fine, seemingly by default, including touch id (or any standard USB key). If it does not, it's because your SSO administrator is intentionally turning it off.
Okta does not have my phone number or an app installed. I do not ever want to be pushed an approval, because I don't know who or what triggered it. I only want to proactively authenticate.
Yeah, pretty much. I explicitly want 2FA with a real 2FA factor on all of my services and all of my machines, but my caveat is that it has to be in my custody - yubikey, totp (not ideal but I do hold an encrypted back up of my seeds that I physically refresh sometimes), fido2, smart card, etc.
Push no. Push on a personal device even more no. SMS and phone absolutely FUCK NO for any reason.
You can put TOTP 2FA keys on anything. A yubikey. An app on your computer. In your password manager. Hell, build your own device from parts: https://hackaday.com/2018/01/04/two-factor-authentication-wi... . If you're forced to use SMS-based 2FA, I can't give you anything but my condolences because SMS-2FA is stupid. But most 2FA systems work with the very flexible TOTP keys so I don't understand the complaints.
As developers, I think we need to think about how we reach this situation where we rely so badly on 3rd party dependencies to do our jobs.
There was a time when all we need as a framework like Django or Rails to write our code on top of it with few 3rd party dependencies, usually something that we could copy to our own repo, read and verify the code and be happy.
Now, no matter what ecosystem you are, it could be Python, Javascript or something else, you end up with hundreds of dependencies even for trivial and basic apps.
How did this happen?
Maybe it is the time to rethinking what we have doing.
Armin, how much of the opposition to 2FA boils down to the "criticality" cutoff? Would you be less opposed to 2FA for publishing to these repos if everyone was subject to the same requirements? I say this because I like cargo-vet (and cargo-crev, etc.), but also I often feel like these package hosts should just have mandatory 2FA anyway as an extra level of security, but also it seems like there's quite a few people who are just opposed to 2FA in general and see it as burdensome.
> On Friday I along many others in the Python community "congratulated" me on having created a critical package. Once packages are within a certain level of adoption compared to the global downloads, they are considered critical.
Does he at least get a blue checkmark next to his account name?
This is a really boring complaint. 2-factor authentication is not hard or time consuming.
If they start pushing other requirements, sure, I'll complain. Further requirements should take place on another independent 'vetting' layer, like the author suggests. But right now, there's no sign of excessive requirements in the future.
> There is a hypothetical future where the rules tighten. [..] Or the index wants to enable reclaiming of critical packages if the author does not respond or do bad things with the package.
This has already happened at least once on npm, and I think maybe a few times.
I don't like the drama about this. It really is not what being a maintainer should be about.
Open source developers need to learn how to be professional.
We can complain all day about packages that don't get recognition, where the maintainer struggles to maintain it and then we wonder, where's the professionalism?
Enable your 2FA. Allow users to support you financially (support agreement, etc).
> I do not chose to create a “critical” package
To the winner, the spoils. Fame has a cost. Drop your package and ask someone else to maintain it if you can't.
> Open source developers need to learn how to be professional.
No, professionals need to be professional. Some FOSS devs are professionals and should act like it, but many FOSS devs are just hacking around in their spare time and don't owe anyone anything; certainly they're under no obligation to be "professional" with their side projects.
To me this sounds like “I don’t want to do the thing that is obvious and sensible because I just don’t wanna.”
Personal liberty? Sure. But not when your personal liberty negatively impacts the rest of society. Just like how you’re not allowed to shout “fire“ in a movie theater because of the harm it could potentially cause. Your personal liberty ends where danger to others begins. If you don’t want to use 2FA on your Google account, knock yourself out. The context of Pypi is different.
Yes, everybody should be using 2FA. And we should also be looking into how to perform package signing and verification. Of course we should. This isn’t your grandfather’s Internet. These are table stakes in 2022.
I hope that there is a future where Pypi mandates those things because they’re good for everyone. They improve things for the entire ecosystem. I’m sick and tired of discovering that Python packages I depend on are being hacked or typo-squatted by malicious packages.
Oh, and get vaccinated — because it’s exactly the same premise. Stop being selfish.
Getting your computer hacked is a contagious disease. From there, attackers can infest other machines and run social engineering attacks against your friends. Maintainers of popular open source projects are super-spreaders. They can infect a huge number of other people.
2FA is a vaccine that mitigates or prevents spread of this disease. It is unconscionably selfish to refuse to harden your accounts just because it's a little inconvenient to you.
Published packages should be immutable. Sure, "unpublish" so it's no longer listed. Even display scary messages in your package manager's stdout. But once you publish a package, any package manager with the hash of the package contents in its lockfile should be able to continue retrieving it indefinitely. The fact that it's possible for any maintainer to break all consumers of their previously published works on a whim is insane to me.
"X wanted me to do Y, which I don't want to do and unambiguously have no obligation to do. I did Z out of curiosity. It broke more things than intended, so I fixed them."
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.