A lot of people seemed to think the author didn't like the switch to 2FA. This isn't the case, as the author linked to https://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling... which says he "2FA all my logins where possible", and in this essay writes "it's a sensible thing."
The concern is that an index - any index - has a lot of power, and can tighten its rules in the future. Indeed, PyPI has tightened its rules since 2022 to require everyone use 2FA, not just the authors of "critical" ones, though staged migration was already part of the plan.
As I understand it, the author believe the index should have "no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies." He proposes a switch to decentralized/independent vetting, to solve supply chain issues 2FA cannot address. One example at https://lucumr.pocoo.org/2022/1/10/dependency-risk-and-fundi... is the "colors" package on npm, where in early 2022 the author deliberately introduced an infinite loop into the code, thus breaking packages which did not pin their colors version. If the author doesn't care about reputation, then there is little 2FA can do.
If I wanted to break supply chain, I would use a pseudonym, develop a useful package, and then pull the trigger.
This is too many for most to vet on their own, and it increases the supply chain risk when any of thousands of independent developers with no legal or contractual liability may be willing to trade off reputation for, say, large financial gain.
I strongly suspect the indexes will tighten the rules in the future as businesses push for even more supply chain assurances. For example, my pseudonym method is harder to pull off if GitHub starts requiring users to register with their real name and a copy of their id.
Speaking now specifically about Python, the very first HN comment from last year says "Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial."
There are several comments along those lines, but I don't think the people who wrote them understand that makes the supply chain issue worse for users.
Suppose I distribute my package that way. 1) If people want their suppliers to use 2FA, how do they know I'm using 2FA to set up the alternate site? 2) pip doesn't have good isolation when using another index, that is, you can't configure pip to install package X and only package X from a third-party site, and use PyPI to resolve other package dependencies.
Instead of 1 index and N developers there are M indices and N developers, giving more ways to attack a supply chain and through a path which has had little hardening over pip's lifetime.
OTOH, the vetting system could handle that - assuming a vetting system could be made to work at all.
A lot of people seemed to think the author didn't like the switch to 2FA. This isn't the case, as the author linked to https://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling... which says he "2FA all my logins where possible", and in this essay writes "it's a sensible thing."
The concern is that an index - any index - has a lot of power, and can tighten its rules in the future. Indeed, PyPI has tightened its rules since 2022 to require everyone use 2FA, not just the authors of "critical" ones, though staged migration was already part of the plan.
As I understand it, the author believe the index should have "no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies." He proposes a switch to decentralized/independent vetting, to solve supply chain issues 2FA cannot address. One example at https://lucumr.pocoo.org/2022/1/10/dependency-risk-and-fundi... is the "colors" package on npm, where in early 2022 the author deliberately introduced an infinite loop into the code, thus breaking packages which did not pin their colors version. If the author doesn't care about reputation, then there is little 2FA can do.
If I wanted to break supply chain, I would use a pseudonym, develop a useful package, and then pull the trigger.
As the author points out, their Rust package has 303 unique dependencies (https://lucumr.pocoo.org/2019/7/29/dependency-scaling/) and the Sentry Javascript front-end had more than 1,000 (https://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling...).
This is too many for most to vet on their own, and it increases the supply chain risk when any of thousands of independent developers with no legal or contractual liability may be willing to trade off reputation for, say, large financial gain.
I strongly suspect the indexes will tighten the rules in the future as businesses push for even more supply chain assurances. For example, my pseudonym method is harder to pull off if GitHub starts requiring users to register with their real name and a copy of their id.
Speaking now specifically about Python, the very first HN comment from last year says "Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial."
There are several comments along those lines, but I don't think the people who wrote them understand that makes the supply chain issue worse for users.
Suppose I distribute my package that way. 1) If people want their suppliers to use 2FA, how do they know I'm using 2FA to set up the alternate site? 2) pip doesn't have good isolation when using another index, that is, you can't configure pip to install package X and only package X from a third-party site, and use PyPI to resolve other package dependencies.
Instead of 1 index and N developers there are M indices and N developers, giving more ways to attack a supply chain and through a path which has had little hardening over pip's lifetime.
OTOH, the vetting system could handle that - assuming a vetting system could be made to work at all.