Congratulations: We now have opinions on your open source contributions
lucumr.pocoo.org
lucumr.pocoo.org
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.
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 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.
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.
Also, as I mentioned before, there's no evidence whatsoever that the 'vet' approach even works, let alone scales.
2FA covers cases where the attacker is not supposed to be authorized to distribute the package. But vet covers all cases where the code isn't doing what it's supposed to do; that includes cases where the attacker wasn't authorized to distribute it, but also cases where the attacker was correctly authorized, or the authorized person simply made a mistake.
An actual disjoint model is something like Go's TOFU proxy, which makes no claims about who was authorized to do what or what the code should be doing, only that it's the same for everyone.
‘I 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.
One option would be for the maintainer to never release an update for their package on PyPI going forward.
… conditions that only need to be met should they wish to continue publishing on PyPi, right?
Users, on the other hand, demand Python software they want to use be available via PyPI. Since both PyPI and software authors are usually trying to act in some users' interest, there should be space for actual discussion and not this zoomer libertarian "nobody owes anyone anything" nonsense.
I 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.
Source: I implemented PyPI’s 2FA.
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.
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.
Don't threaten me with a good time.
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?
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.
Years ago software was just distributed by the developers themselves on their own websites, or by Usenet, or even by floppy disks.
It may well be that the developer wants to be on the index and is willing to pay. In that case, OK. Maintaining an index is not free, so if the indexer needs to charge somebody, it could be users, or it could be developers.
Well it's not years ago, in general most languages have been centralized around a single large index, which gives many advantages but also some disadvantages like seen here. This has been great so far since they've been benevolent, but in cases like npm (which I'm most familiar with) the non-profit Node Foundation joined the private company npm inc. giving it basically exclusive rights. Previous node and npm inc developers have tried to make alternatives, but unfortunately the reality is if you want to publish a JS package today and want anyone to use it, you should use npm.
> Maintaining an index is not free
No, it's indeed probably very profitable when npm was sold to Microsoft, since the npm owners fought tooth and nail before to keep it private and not part of the Node Foundation.
If there is such a significant mismatch in what pypi is going for vs contributors, people will migrate to another solution.
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)
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.
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.
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).
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.
* 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.
Kinda feel like it should. (I also own packages that are critical.)
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.
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.
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".
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
And it's ridiculous for them to do so. How can they verify that the 2FA program is not just being run in a virtual machine? At the end of the day it's the maintainer that decides the security of the package.
Ultimately, PyPI cannot prevent TOTP secret misuse. But we expect the overwhelming majority of users to not misuse TOTP, and a corresponding security advantage therefrom.
> 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.
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?
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.
Currently the "critical package" categorization may offset most of the likelihood of that occurring, although I'd expect there could be problems for some projects even so.
I wonder whether PyPi considered making 2FA-at-publish-time optional and instead offering a question of 2FA-at-package-install-time.
In other words: "pip install --2fa-signed-packages-only" or similar.
It's possible they didn't, or weren't able to, because the ecosystem is already widely deployed and many package version upgrades (including transitive dependencies) occur automatically.
Roughly speaking: I like the author's suggestion (quoted below) of making the the software package ecosystem an immutable (content-addressed?) space, where policies and attestation about whether to use those packages is opt-in based on rules-based overlays. That'd be ambitious but technically feasible, I think.
"So if I were to wish for something, then that the index has no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies."
(that implies that a naive implementation of '--2fa-signed-packages-only' flag would mean 'packages that were published using tokens that were generated by a 2FA-authenticated user; possibly a subtle distinction, but maybe worth mentioning)
Content hosts have hosting rules. Don't like updated rules? Move to another network or self host. You as a platform user have to weigh the pros and cons that come with that decision.
Personally I have stopped contributing to open source due to consumer expectations around free work. My passion projects are now all private and they are all mine or employers who gain from my learnings by paying me. If that's a loss to society, well society can figure out the cost-benefit analysis and get back to me with a better proposal.
Side not: upon going down this rabbit hole, I find that Facebook/Zuckerberg is their primary sponsor[0] and the fact that auth is becoming more of a thing leaves me with zero surprise
Here is my first-hand account: the money that Facebook donated to PyPI was used to pay me to implement 2FA (and a whole bunch of other things). It wasn’t used for any of the current rollout, to the best of my knowledge.
This is a very rational decision. In contrast, I think it is irrational when people keep contributing to OSS while at the same time nurturing resentment towards people who feel entitled to their help, support, or whatever else.
>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.
Ultimately I feel no obligation to contribute to open source or continue to maintain this software. (In fact others have taken over a lot of it for years.) It's a thing I chose to do, I bare the responsibility for those actions. If it gets too much work for someone we should have no bad feeling towards them for walking away.
However maintainers get a lot of bullshit but PyPi are really not contributing to that. There is a slippery slope argument here that I think is just nonsense and in particular I trust people like dstufft and the rest of the team to do their best to avoid contributing to it.
So PyPi team, thanks for this, please feel free to do more.
Yes the package repos have a ton of power. We have a kind of social contract with them to act responsibly so far but all of these platforms are built on a giant pile of donations and free labour. If that contract is violated we'll start finding new solutions. Up until that point I'm happy to let the people with the sweat equity do what they think is right.
I agree with the author that the request is unwarranted. As far as I can tell, most licenses typically have a clause that waive any damages caused by the software along the lines of 'THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER "AS IS"...', so there is absolutely no moral obligation on behalf of the author. e.g:
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.
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?
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].
It's true it's not the fault of the author that a thing became popular. So what?
If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism.
Nobody is forcing you.
That will cause you to have no responsibility. It will likely cause your adoption to be lower, but you just argued that it isn't your fault adoption is so high, so presumably you don't care.
Otherwise you are arguing that you owe nobody anything, because it's not your fault, but the distribution mechanisms owe you something - free distribution without responsibility!
In reality, most people care a lot and want their project to be popular, so making arguments that "it's not the authors fault it is popular" are generally pretty disingenuous.
Whether that is the case here, who knows, but it is pretty hard to be sympathetic to an argument that plays both sides, and claims you owe nobody anything while the distribution mechanisms owe you something.
> If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism.
The rules in a way are changing with the threshold of "criticality". In a way what you are proposing is suggesting to developers to unpublish if they do not want to deal with the complexity of that. This is exactly what happened yesterday accidentally (https://news.ycombinator.com/item?id=32026624). From the responses I have witnessed to that incident I do not believe this a path anyone should take.
> claims you owe nobody anything while the distribution mechanisms owe you something
The post explicitly states that the distribution mechanism doesn't owe developers anything.
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.
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.
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).
The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.
After that, if people want to at some point update to a newer version of the package, yes, they will have to adjust.
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.
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’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.
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.
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.
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.
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.
Rather, if you feel so strongly that something should be done, like vet that software, you could do it.
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?
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).
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.
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.
Edit: I now understand that 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.
https://pypi.org/security-key-giveaway
They're being beyond reasonable. This is outright kind.
They don't.
> 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.
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.
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.
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.
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.
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.
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.
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.
Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".
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?
But then goes on to claim otherwise in the rest of it. :)
Which means that statement does not actually help your cause.
It's not about the rules of the package distribution channel has. It's about the fact that they have different rules for different levels of popularity.
If everyone needed to do 2FA fine. Don't want to do it? Guess you'll distribute your code another way.
But... You can use it and we're going to gladly take your free work and host it and in the process benefit from it (look! It's so simple publishing stuff! Use us) until the liability of hosting you becomes greater than the benefit of hosting you. At that point we need to pull out the adult rulebook and teach you how to properly do things.
So to me it sounds like the distribution channels want to have their cake and eat it too while passing the work to the developers,ie the people that made the distribution channels successful in the first place.
The index wants something for their own reasons, but for some reason considers it reasonable to demand the author do something they want instead of doing the thing they want themselves.
The author provides various ideas for how they could get what they want by doing it themselves or by organizing volunteers who choose to work on that.
It's like demanding a better man-page than the author supplied, instead of writing one or facilitating someone else who may be willing to work on documentation.
If 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.
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.
Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.
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.
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.
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.
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.
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.
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.
> 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.).
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).
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.
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 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.
> 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.
I guess we just need to make signing easy then.
Which remains a hard problem.
sigstore.dev
Anything that makes signing/verifying easier is a welcome change.
Another commenter mentioned sigstore.dev which looks potentially interesting.
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.
I have 3 of them, it is secure and convenient.
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/
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.
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.
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).
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.
Still something like that could be somewhat of a solution. You don't need to use for example 2FA but then you also don't get to publish to everyone today. Then you have to do a security update which would require it.
First of all, it's the slippery slope fallacy. 2FA is not a burden and you can't get any reasonable person worked up because of it. The insinuation that this might lead to other sorts of control is pointless; this possibility has always existed.
Second of all, package indexes have a responsibility to the programming community as a whole and as such I do expect them to make some reasonable demands. This is not infringing on open-source developers' freedom, since nobody forces them to release their code on an official package index.
This post really reads like a storm in a teacup.
* 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'
> 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.
- 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.
I guess some people just have to feel like rebels all the time.
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.
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.
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.
Push no. Push on a personal device even more no. SMS and phone absolutely FUCK NO for any reason.
2FA itself is moot.
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.
Come on people! These Supply chain issues have real world consequences. Y'all act like this is some huge burden.
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.
It’s like remembering a password, make it strong, and keep is safe has no value.
Does he at least get a blue checkmark next to his account name?
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.
This has already happened at least once on npm, and I think maybe a few times.
Go import paths are just easier-to-type URLs.
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.
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.
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.
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.
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.