[zahlman]

>(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]

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]

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]

> 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/

[LtWorf]

> 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…

[zahlman]

Indeed. I have to wonder: if being able to authenticate to GitHub, upload one's code there, and then coordinate a transfer from there to PyPI through the approved mechanisms is good enough... then why can't PyPI just use the same authentication method GitHub does?

It seems hard to justify "we want to ensure the build is reproducible" when there is no system to attempt the build on PyPI's end and the default installer is perfectly happy to attempt the build (when no prebuilt version is available) on the user's machine - orchestrated by arbitrary code, and without confirmation as a default - without a chance to review the downloaded source first.

It seems hard to justify "we want to limit the scope of the authentication" when "a few minutes" is more than enough time for someone who somehow MITMed a major package to insert pre-prepared malware, and access to a single package from a major project affects far more machines than access to every repo of some random unimportant developer.

(The wheel format has hashes, but the sdist format doesn't. If these sorts of attacks aren't meaningfully mitigated by wheel hashes, what is the RECORD file actually accomplishing? If they are, shouldn't sdists have them too?)

[justincormack]

My github credentials are all stored in hardware devices.

[LtWorf]

Yes a computer is a hardware device.