3 ms·

None of this is true. There is no plan to disable API token uploads to PyPI or to mandate Trusted Publishing, much less attestations. It's entirely intended to

None of this is true. There is no plan to disable API token uploads to PyPI or to mandate Trusted Publishing, much less attestations. It's entirely intended to be a misuse-resistant way to upload to the index in the "happy case" where the package uses a CI/CD workflow that supports OpenID Connect. (I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.)

LtWorf 2y ago
I don't think you can predict the future any more than me.
- doctorpangloss 2y ago
  I understand the desire to raise awareness about your fringe concern. But it makes no sense.
- woodruffw 2y ago
  I don't baselessly speculate about it. But yes, I do think I can predict with some confidence that PyPI is not going to remove API token access.
zahlman 2y ago
>(I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.) I sympathize, but there are obvious reasons for this: low trust in the Python packaging system generally (both because of recent PSF activity and because of the history of complications and long-standing problems), and the fact that many similar things have been seen in the Linux and open-source worlds lately (for one example, Linux Mint's new stance on Flatpak and how they present Flatpak options in the Software Manager). (Edit: it also kinda rhymes with the whole "Secure Boot" thing and how much trouble it causes for Linux installation.)
- woodruffw 2y ago
  I personally expect people to have better compartmentalization skills than this. It's both unreasonable and inappropriate to have a general chip on your shoulder, and consequently assume a negative interpretation of an unrelated security effort.
  - LtWorf 2y ago
    It happens that people don't trust you if you are being obviously dishonest. I still have to understand how the github credentials stored on my computer are harder to steal than the pypi credentials stored on the very same computer. If you can explain this convincingly, maybe I'll start to believe some of the things you claim.
    - woodruffw 2y ago
      > I still have to understand how the github credentials stored on my computer are harder to steal than the pypi credentials stored on the very same computer. This is not, and has never been, the argument for Trusted Publishing. The argument is that temporary, automatically scoped credentials are less dangerous than permanent, user scoped credentials, and that an attacker who does steal them will struggle to maintain persistence or pivot to other scoped projects. The documentation is explicit[1] about needing to secure your CI workflows, and treating them as equivalent to long-lived API tokens in terms of security practices. Using a Trusted Publisher does not absolve you of your security obligations; it only reduces the scope of failures within those obligations. [1]: https://docs.pypi.org/trusted-publishers/security-model/ https://docs.pypi.org/trusted-publishers/security-model/
      - LtWorf 2y ago
        > The argument is that temporary, automatically scoped credentials are less dangerous than permanent, user scoped credentials Nobody forced you to implement never expiring global tokens in pypi…
        2y ago

LtWorf 2y ago

I don't think you can predict the future any more than me.

doctorpangloss 2y ago
I understand the desire to raise awareness about your fringe concern. But it makes no sense.
woodruffw 2y ago
I don't baselessly speculate about it. But yes, I do think I can predict with some confidence that PyPI is not going to remove API token access.

zahlman 2y ago

>(I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.) I sympathize, but there are obvious reasons for this: low trust in the Python packaging system generally (both because of recent PSF activity and because of the history of complications and long-standing problems), and the fact that many similar things have been seen in the Linux and open-source worlds lately (for one example, Linux Mint's new stance on Flatpak and how they present Flatpak options in the Software Manager). (Edit: it also kinda rhymes with the whole "Secure Boot" thing and how much trouble it causes for Linux installation.)

woodruffw 2y ago
I personally expect people to have better compartmentalization skills than this. It's both unreasonable and inappropriate to have a general chip on your shoulder, and consequently assume a negative interpretation of an unrelated security effort.
- LtWorf 2y ago
  It happens that people don't trust you if you are being obviously dishonest. I still have to understand how the github credentials stored on my computer are harder to steal than the pypi credentials stored on the very same computer. If you can explain this convincingly, maybe I'll start to believe some of the things you claim.
  - woodruffw 2y ago
    > I still have to understand how the github credentials stored on my computer are harder to steal than the pypi credentials stored on the very same computer. This is not, and has never been, the argument for Trusted Publishing. The argument is that temporary, automatically scoped credentials are less dangerous than permanent, user scoped credentials, and that an attacker who does steal them will struggle to maintain persistence or pivot to other scoped projects. The documentation is explicit[1] about needing to secure your CI workflows, and treating them as equivalent to long-lived API tokens in terms of security practices. Using a Trusted Publisher does not absolve you of your security obligations; it only reduces the scope of failures within those obligations. [1]: https://docs.pypi.org/trusted-publishers/security-model/ https://docs.pypi.org/trusted-publishers/security-model/
    - LtWorf 2y ago
      > The argument is that temporary, automatically scoped credentials are less dangerous than permanent, user scoped credentials Nobody forced you to implement never expiring global tokens in pypi…
      - 2y ago