Congratulations: We now have opinions on your open source contributions(lucumr.pocoo.org)
lucumr.pocoo.org
Congratulations: We now have opinions on your open source contributions
https://lucumr.pocoo.org/2022/7/9/congratulations/
223 comments
> 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 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.
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.
[deleted]
2fa aims to reduce the volume of released attacker controlled code prior to release.
vet aims to reduce the volume of attacker controlled code and accidentally dangerous code after release.
they operate on distinctly different timelines, against different threat models, with different actors.
vet aims to reduce the volume of attacker controlled code and accidentally dangerous code after release.
they operate on distinctly different timelines, against different threat models, with different actors.
Regarding the threat model and actors, the vet approach seems a superset of the 2FA approach, not really different.
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.
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.
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.
The symmetrical position:
‘I think as the distributor of open source developers’ work, I can’t demand much from them’
The question is about maintaining a sustainable balance in the in-kind value each side perceives.
‘I think as the distributor of open source developers’ work, I can’t demand much from them’
The question is about maintaining a sustainable balance in the in-kind value each side perceives.
PyPI is not demanding that OS devs publish their code on their platform.
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.
One option would be for the maintainer to never release an update for their package on PyPI going forward.
> unilaterally imposed conditions
… conditions that only need to be met should they wish to continue publishing on PyPi, right?
… conditions that only need to be met should they wish to continue publishing on PyPi, right?
That's not the symmetrical position. PyPI demands nothing of anyone. It provides a free service with terms of use.
Symmetrically, the author demands nothing of anyone. They provide free code with terms of use.
Which they can host elsewhere.
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.
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.
> complex passwords yesterday, 2FA today, package signing tomorrow, reproducible builds the next.
Don't threaten me with a good time.
Don't threaten me with a good time.
Exactly, just let the version on pypi bitrot and get security issues. It's a great win for their policy.
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.
PyPI does not use SMS 2FA. It only supports WebAuthn (which is preferred) and TOTP.
Source: I implemented PyPI’s 2FA.
Source: I implemented PyPI’s 2FA.
Maybe also mention eligible maintainers can also get free titan security keys (with free shipping). This should reduce the burden even further.
https://pypi.org/security-key-giveaway/
https://pypi.org/security-key-giveaway/
Cheers. I love when this happens on HN.
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.
fun in this comment thread.
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.
fun in this comment thread.
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.
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.
Please keep up the excellent work, I'm very encouraged by what I'm seeing from PyPI.
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.
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?
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.
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.
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.
> Years ago software was just distributed...
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.
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.
Whilst not impossible, as soon as that's done, it adds all sorts of unintended consequences
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.
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'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)
> which started out as the butt of every supply chain joke
Mostly because 99% of developers knows nothing about supply chain attacks and leftpad blew up.
Both npm and rust should force 2FA. Thankfully, crates.io forces github SSO, and github will eventually force 2FA.
Mostly because 99% of developers knows nothing about supply chain attacks and leftpad blew up.
Both npm and rust should force 2FA. Thankfully, crates.io forces github SSO, and github will eventually force 2FA.
> Thankfully, crates.io forces github SSO.
Ouch. That must be difficult for any Rust package maintainers whose GitHub accounts were deleted a few months ago due to the Russian war sanctions.
Ouch. That must be difficult for any Rust package maintainers whose GitHub accounts were deleted a few months ago due to the Russian war sanctions.
Yes, Putin is a piece of shit, unfortunately.
Then make sure the index is owned by a cooperative of all the developers (with appropriate ground rights), not by some arbitrary third party?
I felt this was a thoughtful writeup!
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).
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.
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.
* 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.
> Enabling 2FA on PyPI controls access to PyPI’s web interface, not publishing workflows.
Kinda feel like it should. (I also own packages that are critical.)
Kinda feel like it should. (I also own packages that are critical.)
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.
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.
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".
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
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
Author here.
> 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.
> 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.
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?
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.
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.
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
[0] https://pypi.org/sponsors/
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
[0] https://pypi.org/sponsors/
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.
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.
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."
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)
(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.
>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.
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.
First, thank you for your contributions :)
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:
https://choosealicense.com/licenses/bsd-4-clause/
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.
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:
https://choosealicense.com/licenses/bsd-4-clause/
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.
> Yet, PyPI is the go-to distribution channel
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?
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.
and yet npm still keeps being used.
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].
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.
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.
Author here:
> 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.
> 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?
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).
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.
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.
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.
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.
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.
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.
[deleted]
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.
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.
> 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.
https://developer.apple.com/support/authentication/ ?
https://developer.apple.com/support/authentication/ ?
Not for 2FA, for absolving yourself of all responsibility.
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.
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.
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.
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".
Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".
I find it bizarre that they don't ask for 2FA for all contributions. Possibly a historical inheritance?
Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.
Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.
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.
> 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.
> they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.
No, a TOTP app is also allowed.
No, a TOTP app is also allowed.
Well then, that's perfectly reasonable.
To tack on, they're actually giving away those tokens for free for those who request one.
https://pypi.org/security-key-giveaway
They're being beyond reasonable. This is outright kind.
https://pypi.org/security-key-giveaway
They're being beyond reasonable. This is outright kind.
> Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.
They don't.
They don't.
[deleted]
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.
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.
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.
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.
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.
Caveat: Not everyone in FOSS is American, but…
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.
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.
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 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.
No, they simply take away your rights to publish your creation to their index.
You can always publish your creation on your website or wherever.
You can always publish your creation on your website or wherever.
> 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).
[1] - https://news.ycombinator.com/item?id=32026624
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).
[1] - https://news.ycombinator.com/item?id=32026624
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.
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?
So what? Users can do that if the maintainer chooses to move hosting.
Sure, accepted. That'd be a disruptive change, though, and I think that a better approach is possible.
The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.
The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.
There is no reason the index can't do the extra thing they want for their own reasons themselves.
There is no valid reason to demand the already-a-volunteer do anything extra to supply something they want for their own reasons.
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.
There is no valid reason to demand the already-a-volunteer do anything extra to supply something they want for their own reasons.
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.
> 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.
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.
Rather, if you feel so strongly that something should be done, like vet that software, you could do it.
You don't have to do anything?
"The post explicitly states that the distribution mechanism doesn't owe developers anything."
But then goes on to claim otherwise in the rest of it. :)
Which means that statement does not actually help your cause.
But then goes on to claim otherwise in the rest of it. :)
Which means that statement does not actually help your cause.
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?
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.
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.
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.
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.
A flag would provide choice and unburden everyone.
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.
[deleted]
> Nobody is forcing you.
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.
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.
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 author doesn't want anything.
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.
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.
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.
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’m not at all confused about the obligations.
You seem to be confusing requests and demands.
PyPi requests that you take certain steps once your package is deemed critical. If you don’t, they prevent you from releasing new versions.
You seem to be confusing requests and demands.
PyPi requests that you take certain steps once your package is deemed critical. If you don’t, they prevent you from releasing new versions.
[deleted]
The author presents a perfectly reasonable alternative with argumentation supporting the position. There is nothing in the article about being forced.
Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.
Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.
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.
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.
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.).
> 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).
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.
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.
Once you start accepting payment for something, more responsibilities are implied.
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.
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.
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?
From the article:
> The message to me as a maintainer is quite clear: once a project achieved criticality, then the index wants to exercise a certain amount of control
I don't think that's the definition of control. Pypi gains no power with this, only more work.
And 2FA is really not a big deal.
> One could imagine that an index would like to enforce cryptographic signing of newly released packages.
Yes. Please yes.
Letsencrypt was a boon to the web.
Having a quick way to sign your package to send it so pypi would be a great thing.
This is a long article over nothing.
> The message to me as a maintainer is quite clear: once a project achieved criticality, then the index wants to exercise a certain amount of control
I don't think that's the definition of control. Pypi gains no power with this, only more work.
And 2FA is really not a big deal.
> One could imagine that an index would like to enforce cryptographic signing of newly released packages.
Yes. Please yes.
Letsencrypt was a boon to the web.
Having a quick way to sign your package to send it so pypi would be a great thing.
This is a long article over nothing.
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.
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.
In this particular case, Pypi is giving away hardware security key.
I have 3 of them, it is secure and convenient.
I have 3 of them, it is secure and convenient.
With root certificates, gov already have complete ability to MITM your https connection.
> Having a quick way to sign your package to send it so pypi would be a great thing.
I guess we just need to make signing easy then.
Which remains a hard problem.
I guess we just need to make signing easy then.
Which remains a hard problem.
We've been working with PyPI to help integrate Sigstore, which makes signing (and verification) easier!
sigstore.dev
sigstore.dev
I'll have to check out sigstore.
Anything that makes signing/verifying easier is a welcome change.
Anything that makes signing/verifying easier is a welcome change.
What, exactly, is hard about signing?
We used to say that about https, and now we got letsencrypt.
LE made SSL/TLS easy, we need something similar for sign/verify of packages/software.
Another commenter mentioned sigstore.dev which looks potentially interesting.
Another commenter mentioned sigstore.dev which looks potentially interesting.
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.
[1] https://sos.dev/
[2] https://github.com/ossf/scorecard
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.
[1] https://sos.dev/
[2] https://github.com/ossf/scorecard
FWIW, I also maintain a "critical" package, and I'm happy that the index is requiring 2FA for it.
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.
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.
For all the heartache in open source right now, taking a hardcore stance against MFA is a weird hill to die on
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.
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.
[deleted]
> 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).
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.
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.
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.
Slippery slope nonsense. Use 2 factor.
Jeez.
This is laughable.
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.
This post really reads like a storm in a teacup.
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.
This post really reads like a storm in a teacup.
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'
* 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'
Nobody is forcing anyone to use particular devices. Those are optional. Only 2FA itself is mandatory.
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.
> 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.
Timeo Danaos et dona ferentes. All in all, bad optics and fishy offerings. TOTP is definitely OK.
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.
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).
Power structures are everywhere.
- 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).
Power structures are everywhere.
How anyone can get this worked up because of 2FA is simply beyond me.
I guess some people just have to feel like rebels all the time.
I guess some people just have to feel like rebels all the time.
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.
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.
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.
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.
Oh, hey, I totally didn't even think of that. Of course a Yubikey (or whatever) would work there, too. Looks like Duo will work with FIDO2, too.
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.
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.
I'm less interested in 2FA than the decision that folks will lose access if they don't enable it.
2FA itself is moot.
2FA itself is moot.
I am saddened by the author's take on 2FA. I am saddened that so many in this community share his POV.
Come on people! These Supply chain issues have real world consequences. Y'all act like this is some huge burden.
Come on people! These Supply chain issues have real world consequences. Y'all act like this is some huge burden.
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.
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.
Specially at the end of the day, 2FA really means auth by your phone as you can always reset your password.
It’s like remembering a password, make it strong, and keep is safe has no value.
It’s like remembering a password, make it strong, and keep is safe has no value.
Pip can install from a Git URL. If the author wanted to make a stand they can deprecate their PyPI package and support decentralized distribution.
They should just have required 2fa for everyone.
> 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?
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.
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.
This has already happened at least once on npm, and I think maybe a few times.
Great argument for avoiding centralized repositories.
Go import paths are just easier-to-type URLs.
Go import paths are just easier-to-type URLs.
I only just now realised that PyPI stands for Python Package Index.
Hey, have at it. Infact, I hope your opinions are as controversial and viral as possible. As they say, "no such thing as bad publicity" :D
The apostrophe use in this post is out of control.
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.
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.
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.
Yes, nobody needs to be a professional, and nobody has to brush their teeth in the morning neither
Feel free to not publish through PyPi either
"Maintainers" who can't be bothered to activate 2FA make me lose trust in their code quality.
Feel free to not publish through PyPi either
"Maintainers" who can't be bothered to activate 2FA make me lose trust in their code quality.
This is only a surprise if you thought Open Source wasn't you slaving away for big tech.
Much ado about nothing.
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.
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.
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.
hprotagonist(3)
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.