Look PyPA, no tokens!

You can't steal a token which is never materialised

Trusty Pub: an inventory of the Trusted Publishing status of the top 15,000 packages on PyPI, and collection of all tracking issues on the subject (both prospective or discussed, as well as prior and successful implementations).

Of the top 100 packages on PyPI, the Python Package Index, ~half have set up Trusted Publishing (henceforth TP). In the top 15k that drops to 1 in 5: however if you reweight by package downloads it's closer to the top 100's 50% figure.

I know this after I tabulated this (with a combination of rules for detecting it in GitHub Actions workflow source code, a little PyPI scraping, and manual checking). I tried to get this info from the API but either due to unfamiliarity or it not being exposed, I could only get it from the PyPI project pages.

But why exactly is TP advisable? With the caveat that this mainly applies to projects already publishing on a CI provider like GitHub Actions, there are two reasons.

1. You can't exfiltrate what is never materialised

The first principled reason for them is that not having tokens in your CI environment takes the risk of their exfiltration from secrets out of the equation.

The PyPI API key is a special type of auth token called a 'macaroon' (random tidbit I read on the forums, see the 2014 paper for details), but are still ultimately a long-lived credential.

They are superseded by OpenID Connect (OIDC) tokens (also 2014) which are an auth layer on top of the OAuth 2.0 framework. PyPI has set up agreements with GitHub, Google Cloud, Gitlab, and ActiveState to exchange these OIDC tokens from the platform itself, meaning the user no longer needs to concern themselves with auth creds and their safekeeping.

2. Supply chain assertations compose

The second is that the assertations made by Trusted Publishing (which seems to have effectively supserseded the wheel signing process) can 'compose' into higher order assertations of the entire supply chain.

Tools like "Syft" and "Grype" are medieval-sounding 'software composition analysis' programs that check these assertions, typically used at companies regulated by the EU Cyber Resilience Act or US Secure Software Development Framework. For more on this topic, read the 2025 proposal PEP 770: Improving measurability of Python packages with Software Bill-of-Materials.

This seems like more of a niche concern in industry, but perhaps in the future we may find out the hard way that this is actually something that ought be enforced by civilians too.