3 ms·

> I don't understand this claim -- are you saying that 2FA adds no protection of value in the context of package maintainership, or that does nothing in general

by dvt 4y ago

> I don't understand this claim -- are you saying that 2FA adds no protection of value in the context of package maintainership, or that does nothing in general? I'm trying to say two things: (1) that 2FA adds little, if any, protection of value in the context of package maintainership. In other words, if someone wants to be a malicious actor (say, they had a "legitimate" package from versions 1.0 to 2.1, but 2.2 contains a trojan), they can do it even with 2FA. And (2), it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with. If you're 15 or 16 years old, excited to finally get your package on PyPI, but all of a sudden, you have to jump through all these hoops, including doxxing yourself and providing a real phone number, you would 100% be deterred.

woodruffw 4y ago
> In other words, if someone wants to be a malicious actor (say, they had a "legitimate" package from versions 1.0 to 2.1, but 2.2 contains a trojan), they can do it even with 2FA. That's a different threat model. We're talking about account takeover, which is a separate risk from maintainers going rogue. 2FA addresses the former; the latter is difficult to address in the general case. Nevertheless, it's something that people are tackling both with static analysis and "reputational" schemes. > it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with You're right, which is why it's not mandatory for everyday users. The decision to enable 2FA for "critical" packages is a practical and calculated one: most critical packages are maintained not by brand new PyPI users, but by seasoned engineers who understand their centrality to the ecosystem and the importance of measures that secure their work. There's no current plan to make 2FA mandatory for every single user; the threat model doesn't justify it. > including doxxing yourself and providing a real phone number, you would 100% be deterred. I'm not sure what this has to do with PyPI. PyPI does not and has never supported SMS 2FA. This was an intentional design decision on my part. The only supported 2FA methods are TOTP and WebAuthn, both of which can (and do, by default) preserve nominal anonymity. No phone numbers are involved.

by dvt 4y ago

woodruffw 4y ago

> In other words, if someone wants to be a malicious actor (say, they had a "legitimate" package from versions 1.0 to 2.1, but 2.2 contains a trojan), they can do it even with 2FA. That's a different threat model. We're talking about account takeover, which is a separate risk from maintainers going rogue. 2FA addresses the former; the latter is difficult to address in the general case. Nevertheless, it's something that people are tackling both with static analysis and "reputational" schemes. > it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with You're right, which is why it's not mandatory for everyday users. The decision to enable 2FA for "critical" packages is a practical and calculated one: most critical packages are maintained not by brand new PyPI users, but by seasoned engineers who understand their centrality to the ecosystem and the importance of measures that secure their work. There's no current plan to make 2FA mandatory for every single user; the threat model doesn't justify it. > including doxxing yourself and providing a real phone number, you would 100% be deterred. I'm not sure what this has to do with PyPI. PyPI does not and has never supported SMS 2FA. This was an intentional design decision on my part. The only supported 2FA methods are TOTP and WebAuthn, both of which can (and do, by default) preserve nominal anonymity. No phone numbers are involved.