Hacker News new | ask | show | jobs
by djhaskin987 1438 days ago
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...

4 comments

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

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

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

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.
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.
Or you just maintain it?
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.
These weaknesses are implementation specific. FIDO2/U2F is unphishable, requires proof of presence, and is a significant security win over a strong password.
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.

They've been offering people hardware keys for free.

https://pypi.org/security-key-giveaway/

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.