15 ms·

Congratulations: We now have opinions on your open source contributions

242 points by the_mitsuhiko 4y ago

bbayles 4y ago
FWIW, I also maintain a "critical" package, and I'm happy that the index is requiring 2FA for it.
josephcsible 4y ago
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".
- __s 4y ago
  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
  - cowtools 4y ago
    >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.
    - striking 4y ago
      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 https://pypi.org/help/#totp
      - josephcsible 4y ago
        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.
        woodruffw 4y ago
        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.
  - the_mitsuhiko 4y ago
    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.
    - jayofdoom 4y ago
      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.
    - __s 4y ago
      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?
- jka 4y ago
  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."
  - jka 4y ago
    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)
- Fordec 4y ago
  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/ https://pypi.org/sponsors/
  - woodruffw 4y ago
    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.
  - avgcorrection 4y ago
    > 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.
- Groxx 4y ago
  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.
zbird 4y ago
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/ 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.
- bastawhiz 4y ago
  > 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?
  - zbird 4y ago
    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.
secondcoming 4y ago
I only just now realised that PyPI stands for Python Package Index.
ctoth 4y ago
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.
- staticassertion 4y ago
  > 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.
kevin_thibedeau 4y ago
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.
belfalas 4y ago
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).
- politician 4y ago
  > 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.
__alexs 4y ago
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.
kazinator 4y ago
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.
xg15 4y ago
> 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?
perrygeo 4y ago
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.
- eesmith 4y ago
  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.
givemeethekeys 4y ago
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
creatonez 4y ago
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.
bastawhiz 4y ago
For all the heartache in open source right now, taking a hardcore stance against MFA is a weird hill to die on
petters 4y ago
They should just have required 2fa for everyone.
greatgib 4y ago
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.
tonnydourado 4y ago
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.
jrockway 4y ago
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.
rogers12 4y ago
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.
pwdisswordfish0 4y ago
The apostrophe use in this post is out of control.
woodruffw 4y ago
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.
- toxik 4y ago
  > 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.)
  - woodruffw 4y ago
    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.
    - dlor 4y ago
      And I hear this is improving to allow short-lived publication tokens and federation to prevent them from being leaked :)
      - woodruffw 4y ago
yencabulator 4y ago
Great argument for avoiding centralized repositories. Go import paths are just easier-to-type URLs.
operantoperator 4y ago
> 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).
bravetraveler 4y ago
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].
kibwen 4y ago
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.
nmstoker 4y ago
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.
wyldfire 4y ago
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/ https://sos.dev/ [2] https://github.com/ossf/scorecard https://github.com/ossf/scorecard
akagusu 4y ago
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.
peteypao 4y ago
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.
oxff 4y ago
This is only a surprise if you thought Open Source wasn't you slaving away for big tech.
Izkata 4y ago
> 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.
skyzyx 4y ago
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.
morelisp 4y ago
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?
deleted 4y ago
[deleted]
hprotagonist 4y ago
- smegsicle 4y ago
  how embarrassing to have such a janky CI pipeline!
- Groxx 4y ago
  "X wanted me to do Y, which I don't want to do and unambiguously have no obligation to do. I did Z out of curiosity. It broke more things than intended, so I fixed them." That hardly sounds like a snit.
- infogulch 4y ago
  Published packages should be immutable. Sure, "unpublish" so it's no longer listed. Even display scary messages in your package manager's stdout. But once you publish a package, any package manager with the hash of the package contents in its lockfile should be able to continue retrieving it indefinitely. The fact that it's possible for any maintainer to break all consumers of their previously published works on a whim is insane to me.
  - emu 4y ago
    If pypi didn't enforce size limits, I'd agree with you. We routinely have to delete older versions of our package to make space for newer versions.
  - throwawaybutwhy 4y ago
    A thousand times this. Immutability, reproducibility, traceability. What irks one the most is the arbitrary discrimination between 'critical' and 'non-critical' maintainers. Use TOTP for everybody and be done with it.
TazeTSchnitzel 4y ago
Reminds me of https://news.ycombinator.com/item?id=27106448 https://news.ycombinator.com/item?id=27106448
simonw 4y ago
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".
Tainnor 4y ago
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.
- throwawaybutwhy 4y ago
  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'
  - Tainnor 4y ago
    Nobody is forcing anyone to use particular devices. Those are optional. Only 2FA itself is mandatory.
  - duskwuff 4y ago
    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.
    - throwawaybutwhy 4y ago
      Timeo Danaos et dona ferentes. All in all, bad optics and fishy offerings. TOTP is definitely OK.
hgs3 4y ago
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.
- SoftTalker 4y ago
  Once you start accepting payment for something, more responsibilities are implied.
BiteCode_dev 4y ago
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.
- nibbleshifter 4y ago
  > 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.
  - dlor 4y ago
    We've been working with PyPI to help integrate Sigstore, which makes signing (and verification) easier! sigstore.dev
    - nibbleshifter 4y ago
      I'll have to check out sigstore. Anything that makes signing/verifying easier is a welcome change.
  - BiteCode_dev 4y ago
    We used to say that about https, and now we got letsencrypt.
    - nibbleshifter 4y ago
      LE made SSL/TLS easy, we need something similar for sign/verify of packages/software. Another commenter mentioned sigstore.dev which looks potentially interesting.
  - 4y ago
DannyBee 4y ago
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.
- brabel 4y ago
  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.
  - staticassertion 4y ago
    > 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.
hoten 4y ago
Slippery slope nonsense. Use 2 factor. Jeez.
rubyist5eva 4y ago
colechristensen 4y ago
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.
- ctoth 4y ago
  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.).
  - travisjungroth 4y ago
    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).
frenet 4y ago
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.
submeta 4y ago
Much ado about nothing.
raverbashing 4y ago
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.
- yjftsjthsd-h 4y ago
  > 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.
  - raverbashing 4y ago
    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.
crumpled 4y ago
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?
- __alexs 4y ago
  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.
  - nmstoker 4y ago
    Whilst not impossible, as soon as that's done, it adds all sorts of unintended consequences
- pishpash 4y ago
  Then make sure the index is owned by a cooperative of all the developers (with appropriate ground rights), not by some arbitrary third party?
- staticassertion 4y ago
  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.
otikik 4y ago
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.
hartator 4y ago
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.
staticassertion 4y ago
Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial. Or you can just put your code on github. Or pastebin. Or nowhere. As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems. Sorry but I just do not care at all about this "burden" that you may feel because you've been asked to enable 2FA for a site that hosts your code for free. A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced. Ultimately, > I think as an Open Source developer who is using the index for free, I can't demand much from it. I feel like the article could have been this one line, and then there could have been a separate post discussing the merits of 2fa vs vet.
- mschild 4y ago
  > 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.
  - staticassertion 4y ago
    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.
bjt2n3904 4y ago
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.

242 points by the_mitsuhiko 4y ago

FWIW, I also maintain a "critical" package, and I'm happy that the index is requiring 2FA for it.

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".

__s 4y ago
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
- cowtools 4y ago
  >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.
  - striking 4y ago
    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 https://pypi.org/help/#totp
    - josephcsible 4y ago
      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.
      - woodruffw 4y ago
        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.
- the_mitsuhiko 4y ago
  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.
  - jayofdoom 4y ago
    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.
  - __s 4y ago
    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?
jka 4y ago
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."
- jka 4y ago
  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)
Fordec 4y ago
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/ https://pypi.org/sponsors/
- woodruffw 4y ago
  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.
- avgcorrection 4y ago
  > 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.
Groxx 4y ago
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.

zbird 4y ago

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/ 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.

bastawhiz 4y ago
> 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?
- zbird 4y ago
  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.

secondcoming 4y ago

I only just now realised that PyPI stands for Python Package Index.

ctoth 4y ago

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.

staticassertion 4y ago
> 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.

kevin_thibedeau 4y ago

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.

belfalas 4y ago

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).

politician 4y ago
> 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.

__alexs 4y ago

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.

kazinator 4y ago

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.

xg15 4y ago

> 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?

perrygeo 4y ago

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.

eesmith 4y ago
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.

givemeethekeys 4y ago

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

creatonez 4y ago

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.

bastawhiz 4y ago

For all the heartache in open source right now, taking a hardcore stance against MFA is a weird hill to die on

petters 4y ago

They should just have required 2fa for everyone.

greatgib 4y ago

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.

tonnydourado 4y ago

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.

jrockway 4y ago

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.

rogers12 4y ago

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.

pwdisswordfish0 4y ago

The apostrophe use in this post is out of control.

woodruffw 4y ago

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.

toxik 4y ago
> 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.)
- woodruffw 4y ago
  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.
  - dlor 4y ago
    And I hear this is improving to allow short-lived publication tokens and federation to prevent them from being leaked :)
    - woodruffw 4y ago

yencabulator 4y ago

Great argument for avoiding centralized repositories. Go import paths are just easier-to-type URLs.

operantoperator 4y ago

> 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).

bravetraveler 4y ago

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].

kibwen 4y ago

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.

nmstoker 4y ago

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.

wyldfire 4y ago

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/ https://sos.dev/ [2] https://github.com/ossf/scorecard https://github.com/ossf/scorecard

akagusu 4y ago

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.

peteypao 4y ago

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.

oxff 4y ago

This is only a surprise if you thought Open Source wasn't you slaving away for big tech.

Izkata 4y ago

> 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.

skyzyx 4y ago

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.

morelisp 4y ago

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?

deleted 4y ago

[deleted]

hprotagonist 4y ago

smegsicle 4y ago
how embarrassing to have such a janky CI pipeline!
Groxx 4y ago
"X wanted me to do Y, which I don't want to do and unambiguously have no obligation to do. I did Z out of curiosity. It broke more things than intended, so I fixed them." That hardly sounds like a snit.
infogulch 4y ago
Published packages should be immutable. Sure, "unpublish" so it's no longer listed. Even display scary messages in your package manager's stdout. But once you publish a package, any package manager with the hash of the package contents in its lockfile should be able to continue retrieving it indefinitely. The fact that it's possible for any maintainer to break all consumers of their previously published works on a whim is insane to me.
- emu 4y ago
  If pypi didn't enforce size limits, I'd agree with you. We routinely have to delete older versions of our package to make space for newer versions.
- throwawaybutwhy 4y ago
  A thousand times this. Immutability, reproducibility, traceability. What irks one the most is the arbitrary discrimination between 'critical' and 'non-critical' maintainers. Use TOTP for everybody and be done with it.

TazeTSchnitzel 4y ago

Reminds me of https://news.ycombinator.com/item?id=27106448 https://news.ycombinator.com/item?id=27106448

simonw 4y ago

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".

Tainnor 4y ago

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.

throwawaybutwhy 4y ago
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'
- Tainnor 4y ago
  Nobody is forcing anyone to use particular devices. Those are optional. Only 2FA itself is mandatory.
- duskwuff 4y ago
  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.
  - throwawaybutwhy 4y ago
    Timeo Danaos et dona ferentes. All in all, bad optics and fishy offerings. TOTP is definitely OK.

hgs3 4y ago

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.

SoftTalker 4y ago
Once you start accepting payment for something, more responsibilities are implied.

BiteCode_dev 4y ago

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.

nibbleshifter 4y ago
> 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.
- dlor 4y ago
  We've been working with PyPI to help integrate Sigstore, which makes signing (and verification) easier! sigstore.dev
  - nibbleshifter 4y ago
    I'll have to check out sigstore. Anything that makes signing/verifying easier is a welcome change.
- BiteCode_dev 4y ago
  We used to say that about https, and now we got letsencrypt.
  - nibbleshifter 4y ago
    LE made SSL/TLS easy, we need something similar for sign/verify of packages/software. Another commenter mentioned sigstore.dev which looks potentially interesting.
- 4y ago

DannyBee 4y ago

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.

brabel 4y ago
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.
- staticassertion 4y ago
  > 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.

hoten 4y ago

Slippery slope nonsense. Use 2 factor. Jeez.

rubyist5eva 4y ago

colechristensen 4y ago

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.

ctoth 4y ago
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.).
- travisjungroth 4y ago
  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).

frenet 4y ago

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.

submeta 4y ago

Much ado about nothing.

raverbashing 4y ago

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.

yjftsjthsd-h 4y ago
> 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.
- raverbashing 4y ago
  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.

crumpled 4y ago

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?

__alexs 4y ago
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.
- nmstoker 4y ago
  Whilst not impossible, as soon as that's done, it adds all sorts of unintended consequences
pishpash 4y ago
Then make sure the index is owned by a cooperative of all the developers (with appropriate ground rights), not by some arbitrary third party?
staticassertion 4y ago
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.

otikik 4y ago

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.

hartator 4y ago

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.

staticassertion 4y ago

Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial. Or you can just put your code on github. Or pastebin. Or nowhere. As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems. Sorry but I just do not care at all about this "burden" that you may feel because you've been asked to enable 2FA for a site that hosts your code for free. A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced. Ultimately, > I think as an Open Source developer who is using the index for free, I can't demand much from it. I feel like the article could have been this one line, and then there could have been a separate post discussing the merits of 2fa vs vet.

mschild 4y ago
> 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.
- staticassertion 4y ago
  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.

bjt2n3904 4y ago

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.