3 ms·
In particular, if package indexes start introducing additional requirements for developers, as mentioned in the article, then I do worry that it could risk movi
by jka 4y ago
In particular, if package indexes start introducing additional requirements for developers, as mentioned in the article, then I do worry that it could risk moving an unreasonable level of burden onto developers (who may initiate or develop code purely for their own enjoyment).
Currently the "critical package" categorization may offset most of the likelihood of that occurring, although I'd expect there could be problems for some projects even so.
I wonder whether PyPi considered making 2FA-at-publish-time optional and instead offering a question of 2FA-at-package-install-time.
In other words: "pip install --2fa-signed-packages-only" or similar.
It's possible they didn't, or weren't able to, because the ecosystem is already widely deployed and many package version upgrades (including transitive dependencies) occur automatically.
Roughly speaking: I like the author's suggestion (quoted below) of making the the software package ecosystem an immutable (content-addressed?) space, where policies and attestation about whether to use those packages is opt-in based on rules-based overlays. That'd be ambitious but technically feasible, I think.
"So if I were to wish for something, then that the index has no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies."
- jka 4y agoA correction/clarification since writing the parent comment: publication of packages requires an authentication token, and does not require an interactive 2FA challenge. Generating a suitable token for package publication, however, does. (that implies that a naive implementation of '--2fa-signed-packages-only' flag would mean 'packages that were published using tokens that were generated by a 2FA-authenticated user; possibly a subtle distinction, but maybe worth mentioning)