3 ms·

2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" As a user installing from a registry, yo

2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" As a user installing from a registry, you are trusting both the publisher AND the distributor. Consider an attack where the distributor is adding malicious code to 1% of installs. The publisher is not involved in the process and (unless code signing is involved) has no influence. But if code signing is involved, why is 2FA even needed? The signatures themselves should be sufficient proof. So 2FA overall is a solution in the lens that the distributor intermediates the relationship. This need not happen. People can chuck tarballs and post signatures, establishing more direct trust compared to the indirect solution.

woodruffw 4y ago
> 2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" This is not what 2FA asserts in the context of PyPI. It’s used solely for logins to the web frontend, which is where users can manage their projects and the permissions associated with those projects. The idea is to make account takeover more difficult, since that’s (frequently) the first step in malicious package takeover. Assuming that you’re using API tokens to publish to PyPI (which you absolutely should be), having 2FA enabled on your account will not affect any ordinary publishing workflows. We have separate plans to improve PyPI’s support for code signing.
staticassertion 4y ago
They solve different problems. Given a signed package I can say "this is signed by that key". I can't say how that key was registered, or who registered it, etc. 2FA would be where that key registration actually happens.
dataflow 4y ago
That's not even the point of the blog post to begin debating it here. If the the author believes that then he can write a blog post about how 2FA is bad. That's not what we have here though. In fact, he instead says "it's a sensible thing" and his complaint is that it's a slippery slope: "More importantly though is what could come next. There is a hypothetical future where the rules tighten."

woodruffw 4y ago

> 2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" This is not what 2FA asserts in the context of PyPI. It’s used solely for logins to the web frontend, which is where users can manage their projects and the permissions associated with those projects. The idea is to make account takeover more difficult, since that’s (frequently) the first step in malicious package takeover. Assuming that you’re using API tokens to publish to PyPI (which you absolutely should be), having 2FA enabled on your account will not affect any ordinary publishing workflows. We have separate plans to improve PyPI’s support for code signing.

staticassertion 4y ago

They solve different problems. Given a signed package I can say "this is signed by that key". I can't say how that key was registered, or who registered it, etc. 2FA would be where that key registration actually happens.

dataflow 4y ago

That's not even the point of the blog post to begin debating it here. If the the author believes that then he can write a blog post about how 2FA is bad. That's not what we have here though. In fact, he instead says "it's a sensible thing" and his complaint is that it's a slippery slope: "More importantly though is what could come next. There is a hypothetical future where the rules tighten."