Live data from Hacker News

Atomicwrites' old versions have been purged from PyPI

github.com

21–30 of 75 posts

Re: Atomicwrites' old versions have been purged from PyPI

#21
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.'

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.

Re: Atomicwrites' old versions have been purged from PyPI

#22
post #19
post #16

Earlier quoted context omitted.

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 they also deserve some respect.

Yep. Both parties here are within their rights. It's the HN comment about entitlement of the maintainer that I was responding to.

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.

Re: Atomicwrites' old versions have been purged from PyPI

#23
post #13

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 in…

Forcing people to use a token that can be lost is not an improvement. This shit is going to hit the fan when Github turns on mandatory 2FA.

Re: Atomicwrites' old versions have been purged from PyPI

#24
post #17

Earlier quoted context omitted.

His right

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 w…

I agree. The logic is similar to why you can't delete an HN comment once someone replies.

Re: Atomicwrites' old versions have been purged from PyPI

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

Re: Atomicwrites' old versions have been purged from PyPI

#26
post #11
post #9

Earlier quoted context omitted.

2FA hardly adds any security if you already use password manager with long random passwords.

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.

Re: Atomicwrites' old versions have been purged from PyPI

#27
post #21

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.' https://github.com/untitaker/python-atomicwrites Edit: From the bug report 'I d…

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.

The system works.

Re: Atomicwrites' old versions have been purged from PyPI

#28
post #6

From the GitHub README: > 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 l…

>but his response feels more so If we keep treating open source maintainers like they owe us anything, we will have fewer open source maintainers.

> we will have fewer open source maintainers.

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.

No one acted maliciously. Everyone wins.

Re: Atomicwrites' old versions have been purged from PyPI

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

Re: Atomicwrites' old versions have been purged from PyPI

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

[1] https://old.reddit.com/r/Python/comments/vuh41q/pypi_moves_t... [2] https://gist.github.com/jack1142/efe5c89b861a41616aaf8587838...

Post reply on HN