The whole package has now been deprecated by the maintainer:
'PyPI wants me to enable 2FA just because I maintain this package, and both that and the mess resulting from a stunt of mine, I thought it'd be a good time to deprecate this package. Python 3 has os.replace and os.rename which probably do well enough of a job for most usecases.'
'I decided to deprecate this package. While I do regret to have deleted the package and did end up enabling 2FA, I think PyPI's sudden change in rules and bizarre behavior wrt package deletion doesn't make it worth my time to maintain Python software of this popularity for free. I'd rather just write code for fun and only worry about supply chain security when I'm actually paid to do so.'
I can see the maintainers point, even if it may be inconvenient.
That sounds like a best of both worlds. PyPI sets a minimum bar for developer responsibility and you can opt out of publishing to PyPI if you don't want to be that responsible.
This is a bizarrely emotional response to me. PyPI offered to provide a security key to make the maintainer's life easier so it's hard to see this as an "entitled" act. When I see the core infrastructure for open source software ecosystems improve I cheer that effort on.
While I am in full support of not asking too much of open source maintainers a cooperative stance makes the overall situation better for everyone involved. This could have been handled in a better way.
There’s a moral obligation to mitigate harm caused by your project.
I recently ran into a situation where a very old package caused terrible damage.
I contacted the pypi maintainer. He apologized and promised to fix it. Six months later, no changes.
This was a very unusual situation, as the package was the same name as a module later adopted in the standard library.
The author was under the impression the package was literally uninstallable since the code hadn’t been valid Python for over two decades, including the setup script.
I'm not a lawyer or a smart individual but oh boy that's a red flag, just like several other details you offered. With the information available, it sure seems like that's a dependency that should never be brought into a project.
Maybe some people use their side projects to develop software without the bureaucratic crap full time jobs have. And any amount of bureaucracy is too much for his free side project
I had a package which I didn't publish on PyPI, just my web site as a "if you break it, you get to keep the pieces" sort of thing. I didn't even have a PyPI account.
Someone else added it to PyPI without telling me. And people started using it from PyPI.
I started getting messages about it, like PyPI developers asking maintainers to upgrade package metadata to include if it supported Python 3. That's when I realized it was on PyPI in the first place.
I had to contact the original uploaded to get access to the account.
One user even emailed me a question and said I had an obligation to support it, since I put it on PyPI.
I don't really see the problem. You put the code online and someone published it to PyPI. That you got what effectively amounts to spam emails because of that doesn't seem pertinent. Just block the emails. Unfortunately, putting out public communication addresses like emails does indeed invite all kinds of unwanted, unsolicited messaging.
My point was that a personal project that you have on github could still be put onto PyPI by someone else, without you knowing. Even if you actively want to avoid PyPI.
What you want to do about it is a different topic.
Unlike most spam, I can't figure out how to select interesting email about my projects that I want to answer, from emails I don't want to read at all because they make my blood boil, like those asserting that because the project is on PyPI I'm obligated to help them.
It's rather moot now as I haven't gotten emails about it for 8-10 years.
Huh. As a supply-chain issue, is it important to PyPI that the person in charge of the PyPI entry be affiliated with the project, and share reputational risks should the PyPI packager add malware?
That seems like an interesting vector. Find a potentially useful Python package which isn't distributed via PyPI, add an entry using a new account which looks like it's part of the project, add malware, and upload.
> Others would have left it alone or added a note somewhere.
I doubt I'm unique in this regard.
> why doesn't pypi verify that uploader and developer coincide?
How would that verification process work?
I have failed to find a PyPI requirement that they coincide.
It appears that if you have a public repo with a FOSS project but no PyPI entry then anyone is free to use your repo to create a PyPI entry. It's not quite namesquatting given that it's (at least at the start) the same code base.
] None of the following qualify for package name ownership transfer ... User A owns a project X outside the Package Index. User B creates a package under the name X on the Index. After some time, User A wants to publish project X on the Index but realizes name is taken.
EDIT: Someone who avoids submitting to PyPI because of philosophical objections to the PSF Code of Conduct appears to have no recourse should this happen, as the resolution process requires following the PSF Code of Conduct.
And I locked myself out of the first one while (before finishing!) setting up my second, so IMO you need more than two.
(It's not a great story, the tl;dr is I used a different passphrase for the second one, mixed them up, and ploughed through my 3 tries at the passphrase on my first one confident I was getting it right.
I also think that default (Yubikey's) of 3-tries is insanely low, getting it wrong just once is nerve-wracking; how much easier is it to brute-force in 30? That's more guesses of pet names et al. sure but you're not brute forcing it in that. Just don't use a pet name.)
> PyPI wants me to enable 2FA just because I maintain this package, which I don't care for. So this package is now unmaintained.
Just set up a KeepassXC file and put your 2FA info in there? You don't need to give PyPI your phone info, PyPI takes TOTP[1]. 2FA is pretty normal; I don't see why the author has a problem with it. It doesn't violate privacy (since it's not actually tied to any PII like a phone number), it takes like 10 seconds to set up, and it protects your packages from hackers. Perhaps the author simply doesn't see the point of 2FA, since he implies the PyPI authors only did it for compliance reasons (and not for normal bolt-your-doors security reasons, which is more likely)?
He calls setting up 2FA "an expense of my free time" when surely it took more time for him to delete and re-add his package than it would have to just set up 2FA.
EDIT:
To be fair, the maintainer owes us nothing[2], sure. But it's not unreasonable to protect the larger community with basic security practices, either.
We can say the same thing about maintainers of PyPI. They host your libraries and serve it to anyone who wants, free of charge. The only thing they ask in return is to maintain a minimum level of security so that they have less headache in the future.
I think both parties are within their rights, but I also think this is a stupid move on PyPI's part. Maintainers are already working for free; start making them jump through hoops and some will decide it's all too much work and leave.
I think it would be much better to throw up a warning (potentially a loud one) when a dependency is maintained by someone without 2FA.
Packages being taken over because of stolen credentials creates a maintenance nightmare, and bad publicity, for PyPI itself. As such, they have every right, and a reasonable need, to require 2FA. In contrast, the maintainers of PyPI don't lose too much if a few projects choose not to use the platform anymore. Remember, you're not paying PyPI anything either, so the fact that it may inconvenience your own projects, whether free or proprietary, is not their problem.
That isn't necessarily a bad thing. I would be happy to lose every developer who is unwilling to enable 2FA. I am glad to see that that's what happened here. The developer has no responsibility to maintain their code, and PyPI has no responsibility to let them publish their code. Both sides discussed this and an agreement was reached - the developer will no longer publish their code to PyPI.
That's fair, he owes us nothing[1]; I agree with that. But it's not unreasonable to protect the larger community with basic security practices, either.
I am not objecting the 2FA deployment - it's a good idea. I am objecting the attitude towards maintainers which disagree - they have the right to disagree. They owe us nothing.
This is clearly not true. Having a second factor helps maintain security in the situation where your password is compromised (phishing is just one scenario). It isn't perfect, and can itself be defeated. However, compromising an account with 2FA is demonstrably more difficult than one without.
While there are scenarios where 2FA can maintain security where a password is compromised, it's absolutely true that for a large swath of practical threat models, almost the entire benefit of 2FA comes in the form of assigning the shared secret instead of letting the user pick a weak and/or widely-reused password and the "having a second factor" bit doesn't really factor into the picture in any meaningful way.
These weaknesses are implementation specific. FIDO2/U2F is unphishable, requires proof of presence, and is a significant security win over a strong password.
I'm not calling it a weakness. I'm saying that the alleged advantages of the 2F in 2FA don't normally matter to people who just want to their shit to work.
If they can phish my password, they can trivially phish my OTP as well. The one thing I can see actually protecting against that is a physical hardware key, but that's a lot of extra inconvenience.
You know which modules I'm not using for my critical projects? Ones whose maintainers refuse to enable 2fa. We already know how supply chain security problems have plagued npm and pypi. Dependabot should alert you when your dependency comes from a package maintainer that doesn't use 2fa.
I think it's completely insane to not use 2FA when available... but I also support the freedom to not maintain a piece of software unpaid. One person projects are pretty miserable.
I have ADHD. I lose things. I once had to restore access to a 2FA protected account I’d lost the token to. It took weeks of back-and-forth and involved sending personal information (selfies with identity cards) the service had no business knowing.
Never again. Especially for an unpaid personal project for which I owe nobody anything. If PyPI sent me this email, I’d immediately nuke all versions of all packages I maintain, replace with a blank/no code “upgrade” version that contains nothing but a readme explaining what happened, and close/deactivate my account.
I lose things incredibly often too(Like, losing my wallet twice and keys once, all within a 12 month period, going inside and leaving keys in the front door, needing GPS to get home 3 blocks away, etc).
If 2FA was token based as people seem to want it to be, I'd have an issue, but SMS based is enough to keep out the majority of opportunistic attackers while being recoverable. Plus, there's always printable recovery codes with Google at least.
> If 2FA was token based as people seem to want it to be, I'd have an issue, but SMS based is enough to keep out the majority of opportunistic attackers while being recoverable.
But so is using a long, unique, random password stored in a password manager! In fact, a strong password is more secure because it's not vulnerable to SIM swapping.
Admittedly, you could use both, but many/most services will let you use SMS for password recovery once it's set up, so it ends up becoming a single factor!
I'm also really nervous about loosing access to my phone number some day due to some screwup or other.
> Plus, there's always printable recovery codes with Google at least.
But I loose things. Especially slips of paper which I usually don't need to access. There is absolutely no way in hell I will be able to find a printout of backup codes when I actually need them.
Also got this letter of happiness. I don't mind 2FA, already had it set up. But PyPi is weird. I wanted to add a secondary 2FA device for backup, but they would not just let me do it. I had to download recovery codes first. But what am I going to do with them? Unlike 2FA tools there's no convenient way to store them. But because they insisted (and they really did by immediately asking me to burn one of them) I just saved them into a random file on my local disk. I suppose I could delete them, but I would rather not have gotten them in the first place.
PyPI identifies a package as critical and asks the maintainer to enable 2FA.. but allows them to simply delete the package to get around this requirement?
I dunno, I think if you publish a copy of your code to a registry then it would be both desirable and reasonable for that copy to be immutable. Allowing the deletion of published libraries can have huge downstream impacts and ultimately makes the registry less trustworthy.
Edit: to be clear, not trying to shame the author here - it sounds like they tried to avoid this situation: "what i didn't consider is that this would delete old versions. those are apparently now gone and yet it's apparently not possible for me to re-upload them. i don't think that's sensible behavior by pypi, but either way i'm sorry about that."
I think this is a bad design on PyPI's part though.
Apparently when the 2fa requirement is actually implemented (this was just an announcement which triggered this) deleting a package would require 2fa as well.
I assume/ hope that this is PyPI's first step in rolling out mandatory 2FA? Otherwise the whole "you're critical so you have to enable it" seems a bit silly in that you're going to have developers who get critical decide they don't want to do this, and at that point pull packages/ stop maintaining.
Just having a 2FA requirement from the start (or some grace period like 7 days) seems like the way to do it.
Someone on Reddit [1] ran their own version [2] of the query PyPi used to make this determination. Over the last 6 months, atomicwrites was downloaded 38,497,903 times, good for just under #400 by rank.
'PyPI wants me to enable 2FA just because I maintain this package, and both that and the mess resulting from a stunt of mine, I thought it'd be a good time to deprecate this package. Python 3 has os.replace and os.rename which probably do well enough of a job for most usecases.'
https://github.com/untitaker/python-atomicwrites
Edit:
From the bug report
'I decided to deprecate this package. While I do regret to have deleted the package and did end up enabling 2FA, I think PyPI's sudden change in rules and bizarre behavior wrt package deletion doesn't make it worth my time to maintain Python software of this popularity for free. I'd rather just write code for fun and only worry about supply chain security when I'm actually paid to do so.'
I can see the maintainers point, even if it may be inconvenient.