You shouldn't trust Trusted Publishing
35 points by yossarian
35 points by yossarian
This is a good write-up. Trusted Publishing and attestations provide different sets of guarantees against different failure modes, which are both also distinct from what trust means to most users.
Trusted Publishing is only possible because over the past 15 years so many open source projects went from self hosting (mailing lists, git repository, bug tracker, build server) to centralized forges.
Now the downsides of centralized forges are becoming more obvious and projects are considering self-hosting again.
But while in the 2010s it was convenience and the social network aspect that pushed projects to centralized forges, now there are many other factors that lock projects in, including Trusted Publishing.
Mistrust authority – promote decentralization.
— "The Hacker Ethics", from Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)
There is no “lock in” with Trusted Publishing. You can always use another authentication method, including on a host that PyPI knows how to federate with.
(There’s no small irony in calling a federated authentication scheme a form of lock-in.)
Suppose I have a mini-PC in my basement that runs all my CI for my OSS projects. Which docs should I read to understand how to set up trusted publishing from that PC to PyPI?
You would use an API token for that, not Trusted Publishing.
(As mentioned below, there’s marginal-to-negative value in having PyPI federate with every possible server on the Internet. At small scales it’s the same as provisioning an API token directly.)
If you use a third-party CI/CD provider to publish your packages to PyPI, you need to give the provider some sort of credential they can use to publish on your behalf. Trusted Publishing minimizes the scope of the credential you need to give them, and thus (hopefully) the associated blast radius from that credential being leaked/exposed by a system that is not under your control.
If you use your own self-hosted Ci/CD pipeline that you fully own and control, it is not clear to me that you have the same set of problems Trusted Publishing tries to solve, so I'm not sure why you insist you want it, unless it's because you're falling into the trap of believing Trusted Publishing means something other than what it does.
Some registries have deprecated (or discussed deprecating) long-lived API tokens, while pointing at trusted publishing as alternative.
At the same time, registries only support trusted publishing for certain allowlisted services:
Trusted publishing brings enterprise-grade security to your npm publishing workflow and is available today for:
- All npm private and public packages, both scoped and unscoped.
- GitHub Actions (GitHub-hosted runners).
- GitLab CI/CD (gitlab.com shared runners).
I don’t have any insight into those registries. I think that would be a mistake, and I suspect that they’ll also find that removing API tokens entirely is impractical given the long tail of uses on their own infrastructure.
As for supporting other services: this is covered by the shape problem mentioned in the post. I think it would be great if CI/CD services got together and came up with a standard machine identity representation; that would allow registries to enroll arbitrary services without needing to learn each’s claim shape.
(The post is entirely about PyPI.)
over the past 15 years so many open source projects went from self hosting (…) to centralized forges.
Self-hosting has basically always been a minority sport. The point of SourceForge was to take over that burden. And, at about the same time (25+ years ago), the ASF, tho the ASF has a lot of governance baggage as well. Before that was the GNU project, which had a greater emphasis on free software ideology and less emphasis on systematic project hosting services (because GNU predates any clear idea of what services a free software project needs). In the 1990s a free software project would typically live on a university timesharing service or a friend’s colo box (eg PuTTY or Apache httpd before the ASF). It was rare that a project got large enough to justify its own infrastructure. (And affordable hosting is also a relatively new thing.)
Self-hosting has basically always been a minority sport. The point of SourceForge was to take over that burden.
I'm not sure where this assertion comes from. If I look at most libraries and projects I used and contributed to back in the day, they all either were hosted on their own servers or on random university servers (which isn't comparable to a centralised forge).
That effort required in publishing a library also meant they were usually larger and developed by multiple people, avoiding the modern dependency hell and the left-pad disaster.
That was my experience of all the little projects before SourceForge came along. (not GNU, not BSD, not X, not Perl …) They mostly didn’t run their own project infrastructure, they borrowed from someone else and/or went without.
Perhaps you are counting programmers whereas I am counting projects.
Right, most projects had usually the author's email and tarballs somewere, maybe if you're lucky, a web site or mailing list. The amenities of a modern forge like issue tracking, public source control, etc. weren't available to most projects (without a ton of effort) until as you say, SourceForge. The lack of those modern forges also means hosting was also fragile too, as people i.e. graduated university.
I'd say that fewer tiny dependencies was a good thing?
I'd rather have more projects like debian, sqlite, threeten, spring, lwjgl, inspircd, quassel, etc than another few thousand different is-even implementations.
It's also much easier to get companies to contribute to a few larger dependencies financially, than to send a few cents to tenthousand different dependencies.
And fewer, larger dependencies also makes it easier to audit them, join the communities of your upstream dependencies, and contribute back.
Is there any reason you couldn't do trusted publishing from a self-hosted forgejo? If there is, I'm missing it!
There’s no technical reason why you couldn’t, although there are logistical reasons why you can’t with PyPI at the moment.
The short version is that OIDC federation assumes that the party being federated with can/wants to maintain an entire PKI. But at the scale of small hosts, the value of managing a secret key for OIDC purposes versus managing an API token directly leans in favor of the latter.
(This is one of the reasons why “use an API token” is good advice, and why PyPI doesn’t suggest otherwise!)
I believe Forgejo makes it fairly easy to "maintain an entire PKI" and does so by default for OIDC from CI. https://codeberg.org/forgejo/forgejo/pulls/10481 introduced most of this functionality if you want to read about it. This is far more secure than a static token, because the only thing exposed to the potentially untrusted job is a short-lived JWT. Would be really cool if PyPI would let us trust our own Forgejo instances!
I got a lot from this discussion of adding Codeberg as a PyPI Trusted Publisher, which explains both the reasons why PyPI is reluctant and how existing API tokens can be used to similar effect for self-hosted runners by adding caveats. Someone from Codeberg even commented they are "not so confident to pursue this" after reading that.
(This is one of the reasons why “use an API token” is good advice, and why PyPI doesn’t suggest otherwise!)
I think PyPI has definitely settled on the right balance here. npm has been much more aggressive about nudging people towards OIDC over tokens (even in scenarios where OIDC isn't available), and I suspect that's splashing over onto PyPI a bit even though their messaging is quite a bit more measured.
Trusted Publishing often only allows GitHub and the Gitlab.com instance.
Support for self-hosted instances is very recent (after 2 years!), not widely supported, and still in Beta from what I can tell?
https://blog.pypi.org/posts/2025-11-10-trusted-publishers-coming-to-orgs/
Or take NPM:
Trusted publishing brings enterprise-grade security to your npm publishing workflow and is available today for:
- All npm private and public packages, both scoped and unscoped.
- GitHub Actions (GitHub-hosted runners).
- GitLab CI/CD (gitlab.com shared runners).