[HN Gopher] Atomicwrites' old versions have been purged from PyPI
       ___________________________________________________________________
        
       Atomicwrites' old versions have been purged from PyPI
        
       Author : afturner
       Score  : 27 points
       Date   : 2022-07-08 20:35 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | afturner wrote:
       | 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?
        
         | jbverschoor wrote:
         | His right
        
           | dmart wrote:
           | 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.
        
             | Wowfunhappy wrote:
             | I agree. The logic is similar to why you can't delete an HN
             | comment once someone replies.
        
       | staticassertion wrote:
       | 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.
        
       | legobmw99 wrote:
       | 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...
        
       | djhaskin987 wrote:
       | 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 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.
       | 
       | 1: https://pypi.org/help/#twofa
       | 
       | 2:
       | https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
        
         | krasin wrote:
         | >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.
        
           | djhaskin987 wrote:
           | 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.
           | 
           | 1: https://gist.github.com/richhickey/1563cddea1002958f96e7ba
           | 95...
        
             | krasin wrote:
             | 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.
        
           | yongjik wrote:
           | 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.
        
             | krasin wrote:
             | Yep. Both parties here are within their rights. It's the HN
             | comment about entitlement of the maintainer that I was
             | responding to.
        
               | Wowfunhappy wrote:
               | 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.
        
           | staticassertion wrote:
           | > 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.
        
         | lbhdc wrote:
         | I can't blame them, I would have done the same. I assume their
         | priorities are not aligned with pypi and have no incentive to
         | jump through those hoops.
        
         | bvrmn wrote:
         | 2FA hardly adds any security if you already use password
         | manager with long random passwords.
        
           | ary wrote:
           | 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.
        
             | Wowfunhappy wrote:
             | 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.
        
             | naniwaduni wrote:
             | 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.
        
               | staticassertion wrote:
               | These weaknesses are implementation specific. FIDO2/U2F
               | is unphishable, requires proof of presence, and is a
               | significant security win over a strong password.
        
               | Wowfunhappy wrote:
               | Is PyPI requiring maintainers to use a hardware key? If
               | not, I don't understand how this policy is helpful.
               | 
               | Anyone who hadn't already turned on 2FA is going to use
               | the most frictionless so-called second factor they can.
        
         | jbverschoor wrote:
         | Or you just maintain it?
        
       | jamesboehmer wrote:
       | 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.
        
         | Wowfunhappy wrote:
         | That's entirely reasonable. However, it is also reasonable for
         | the author, who is working for free, to ignore your concerns.
        
       | AngusH wrote:
       | 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.
        
         | staticassertion wrote:
         | 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.
        
           | whizzter wrote:
           | I wonder how people who maintain CI pipelines feels about it
           | on monday if they're recalled from vacations because the
           | pipelines broke.
        
       | [deleted]
        
       | ary wrote:
       | 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.
        
         | Wowfunhappy wrote:
         | > PyPI offered to provide a security key to make the
         | maintainer's life easier
         | 
         | It's even easier to just leave 2FA disabled and stop
         | maintaining the project. Which is what they did.
         | 
         | Are maintainers obligated to support their projects
         | indefinitely?
        
         | savant_penguin wrote:
         | 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
        
           | staticassertion wrote:
           | So why publish to PyPI? I have tons of personal projects that
           | never leave my laptop, or, at most, github.
        
         | kevin_thibedeau wrote:
         | 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.
        
       | lostmsu wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2022-07-08 23:01 UTC)