You shouldn't trust Trusted Publishing
ENOSUCHBLOG
Programming, philosophy, pedaling.
Home
Tags
Series
Favorites
Archive
Main Site
TILs
You shouldn't trust Trusted Publishing
Jul 7, 2026
Tags:
oss,
python,
security
…because Trusted Publishing isn’t for you (or me) to trust! It’s for the machines.
Trusted Publishing is an authentication scheme that involves machine-to-machine trust.<br>If you find yourself arguing (or for!) against Trusted Publishing on the basis that<br>you (a human) can’t (or can) trust it then you’re making a category error, one that PyPI<br>is careful to help you not make.
I wrote about this indirectly about two years ago, but I left this observation implicit rather<br>than laying it out explicitly. This is an attempt to correct that mistake.
Quick recap#
“Trusted Publishing” is a term of art that PyPI uses to describe a form of authentication<br>on top of OpenID Connect (OIDC) federation. PyPI released it in 20231, and<br>it’s since been adopted widely by other packaging ecosystems (including npm,<br>RubyGems, crates.io, and NuGet).
The basic observation behind Trusted Publishing is twofold:
Long-lived credentials (like index API tokens) are difficult to secure, and are<br>often over-scoped because users find it frustrating to determine the “right”<br>minimal scope and expiry. Consequently, the impact of a compromised or leaked<br>credential can be much broader than the specific system it was stolen from.
Many users provision credentials solely for the purpose of putting them in a<br>CI/CD platform, which they then publish from. However, CI/CD platforms often<br>also have identity mechanisms that allow a user to demonstrate control of a<br>specific machine identity2 via OIDC.
Trusted Publishing combines these into an authentication scheme: the user<br>performs a one-time registration of their “Trusted Publisher” (their CI/CD machine<br>identity) with their package index. Then, whenever the CI/CD presents an identity<br>token, the package index verifies it and issues a corresponding, minimally scoped,<br>short-lived publishing credential.
This can be hard to visualize; Seth Larson’s diagram is instructive:
(Source: OpenSSF)
Broadly speaking, this approach to short-lived, self-scoping credentials has been a huge success:<br>we’ve found that users3 prefer not to manually manage credentials when they don’t have to,<br>and that large Open Source projects and companies alike both like the property of their publishing<br>being tied to their source identity rather than any individual project maintainer.
Of course, Trusted Publishing is not perfect: it has a complicated data model4,<br>requires bespoke treatment for each OIDC provider that an index chooses to support5,<br>and (of course) can still be compromised (since, at the end of the day, it’s still an<br>authentication scheme and there needs to be a credential somewhere in the flow)6.
Despite these qualifications, I think Trusted Publishing has been a net win for packaging ecosystems<br>that adopt it. As mentioned in the earlier post, security is a matter of identifying and protecting<br>the areas where your users congregate their trust (their “watering holdes”), and Trusted Publishing<br>accomplishes that by reducing the number of long-lived, over-scoped credentials that users are exposed to.
What of trust?#
Thus far, everything I’ve written makes Trusted Publishing sound pretty good, if not a silver bullet.
So, why the emphasis on not trusting it?
This is an important subtlety: Trusted Publishing is just an authentication method .<br>The only thing Trusted Publishing does is establish a trust relationship<br>between an external machine identity (like a CI/CD workflow) and a package identity on an index<br>for the purpose of authenticating an upload ;<br>it does not tell a user that a package is safe to use, high quality, or anything else.
You can prove this to yourself easily: PyPI is a public index (by design), which means that anybody<br>can upload to it, and anybody can use a Trusted Publisher to upload7. Because anybody<br>can use one, they can be used to upload anything, including malware or vulnerable code.<br>They are exactly like API tokens (PyPI’s other upload authentication method) in this regard.
PyPI is very careful8 to not mislead users into believing that they can or should<br>trust a package based on its Trusted Publishing status. If you go to a project’s page on PyPI,<br>you’ll notice that there is no “magic green checkmark” signaling a project’s Trusted Publishing<br>status.
Using zizmor as an example:
Observe that the only “green checkmark” for user-controlled state on this page is for<br>links that PyPI can prove came from the same source as the package itself. These links,<br>too, are intentionally not described as “trusted”; as the PyPI docs explain:
A URL being verified only attests that the URL is under control of the PyPI package owner at the time of verification, and does not imply any additional safety about that URL or any other relationship to the project in question.
If you do want...