“Trust” in the context of Trusted Publishing just means OIDC federation; it’s a way to make explicit the otherwise implicit trust relationship between PyPI and any CI/CD system (specifically, the relationship that happens when a user manually issues an API token and stores it in their CI/CD system’s secrets, effectively trusting the CI/CD to maintain the secrecy of their token.
To your points below: you can make an argument that supporting arbitrary OIDC IdPs would be a harm reduction step, insofar as TP is generally more misuse-resistant than manually issued credentials. But the underlying problems around this have been addressed before: supporting additional OIDC IdPs in PyPI is a nontrivial engineering undertaking (since OIDCs exhibit significant claim diversity), and doing so has limited value if only a handful of packages actually use a given OIDC IdP (since the IdP itself needs to maintain PKI, which at small scales is morally equivalent to maintaining the secrecy of the API token(s) themselves).
In other words the juice is not worth the squeeze; PyPI can better serve the Python community by performing maintenance and working on other features, rather than chasing down all the ways in which FooCorp’s OIDC IdP is slightly different just so 15 packages can be published from it.
(This isn’t to say that PyPI shouldn’t support OIDC IdPs that do demonstrate significant uptake, like Forgejo. I think it should.)
In the context of attestations (which as @dstufft notes is distinct from TP), PyPI does have a mechanism for verifying the honesty of the federated party – attestations are backed by signing keys bound to certificates, and those certificates are committed to an append-only transparency log. The attestations themselves are also committed to a separate log.
In the event of a compromise of GitHub’s OIDC PKI, PyPI (or any other interested party) could audit the transparency log for indicators of malicious activity.
I think I (and others) have been clear that an attestation is not, on its own, any particular signal for trust or quality. What it is from PyPI’s perspective is strong proof that a particular distribution came from a particular place (GitHub, GitLab, Google, or whatever else), which serves two purposes at the moment:
- It addresses a minor form of malicious activity, i.e. putting another repository’s links in the metadata to make the project appear more legitimate or popular than it actually is.
- It makes a handful of incident response tasks (namely around precise timelines) much easier, since the transparency log provides an exact record of the temporality and order of malicious activity in a compromised package.
Apart from these two purposes, attestations could provide direct end-user value if clients were to verify them (upon locking an initial identity set, similar to how Go TOFUs its go.sum on first resolution). But even then, an attestation itself would not be a signal of anything; what it would become is a marker by which to measure changes (e.g. a new version being published _without_an attestation or with a different machine identity).