Am I correct in my understanding that the only trusted publishers are for-profit US companies? And these all use proprietary implementations which cannot easily be replicated elsewhere?

Like, if I want to host on Codeberg, or Sourcehut, what is the process needed for those platforms to become a trusted publisher?

As it happens, I build my releases on my own hardware using a pypa/manylinux release. Can I provide attestation, or am I required to use a third-party service to get that "x Without provenance" removed from my entry?

▲

woodruffw 3 hours ago | parent | next [-]

Support for Codeberg is being discussed here[1]. I think there's broad consensus among PyPI's maintainers and admins that more publisher providers are desired, but we also need them to demonstrate strong key management and rotation controls due to the degree of trust and access that becoming a publisher provider grants them (effectively, they become the PyPI credential broker for the projects that use their service).

(If you pan through that thread, you'll note that one of open issues with Codeberg is that their underlying server wants to store OIDC private keys on disk at the moment. This is okay for small deployments of personal services, but not for something that PyPI needs to federate with and trust.)

[1]: https://github.com/pypi/warehouse/issues/19786

▲

eesmith 2 hours ago | parent | next [-]

So I, as someone who does my builds locally, can never have attested builds?

Will PyPI be presenting warnings or statements of caution which might cause users to be concerned about using my distributions? Or imply that my build practices are somehow inferior to depending on a third-party build system?

▲

guipsp 2 hours ago | parent | next [-]

Yes, that is right - that's the purpose of attesting builds.

Do you see any other alternative?

	▲	woodruffw 2 hours ago \| parent [-]
		The current formats (publish and SLSA provenance) are for attesting publishing and build steps, respectively, but there's nothing stopping PyPI from adding a different, new attestation statement for local builds (something that conveys "I did this locally, and I was this principal (email address) when I did it").

▲

woodruffw 2 hours ago | parent | prev [-]

There's a discussion thread for email attestations here[1]. Those would support local builds.

But to take a step back: if you want attested builds because you think attestation is itself a gold star, then you're working from the wrong priors. Attestations do not imply that a package is secure any more than a hash does; what they are is a cryptographic signature over a set of claims, which allows for authenticated auditing of a project's state over time.

I think PyPI's documentation does a good job of conveying this nuance[2], and that much of the opprobrium of attestations comes from people either not understanding that nuance or imputing conspiracies into it.

[1]: https://github.com/pypi/warehouse/issues/18007

[2]: https://docs.pypi.org/attestations/security-model/#trustwort...

	▲	1299343 2 hours ago \| parent [-]
		[flagged]

▲

tzlahp 2 hours ago | parent | prev [-]

Of course: In principle we'd welcome a change, but there are technical difficulties in perpetuity.

	▲	woodruffw 2 hours ago \| parent [-]
		Storing your private keys somewhere other than a regular file on disk is not a perpetual technical difficulty. Please assume good faith.

▲

eddythompson80 3 hours ago | parent | prev [-]

Sounds like it. Currently it seems you'll need to setup your own OIDC provider[0], then work with PyPI to get them to trust your instance as a "Trusted Publisher". It seems like a system to scale for multi-tenant publishers (like millions of GitHub or GitLab or Google build or ActiveState users). The design itself should be able to scale for individual OIDC providers through webfinger and OIDC discovery like Tailscale does it[1], but it doesn't look like it's there yet. Not sure if it's planned either the github issue mentiones future PyPI verified email attestation, though I'm not sure if that implies webfinger/OIDC like ts does it.

[0] https://docs.pypi.org/trusted-publishers/

[1] https://tailscale.com/docs/integrations/identity/custom-oidc

	▲	woodruffw 2 hours ago \| parent [-]
		> The design itself should be able to scale for individual OIDC providers through webfinger and OIDC discovery like Tailscale does it[1], but it doesn't look like it's there yet. This is the right idea, but it's actually not that simple unfortunately: Trusted Publishing relies on per-IdP claims that are more precise than the `sub` claim (because doing pattern matching on the `sub` claim is brittle and prone to security problems). So we require publisher providers (OIDC IdPs) to provide distinct claims that we can match on. For GitHub and GitLab that's things like the repository name, workflow filename, etc., while for others it might be distinct username and immutable ID claims, etc. This is all downstream of OIDC-driven federation being a much weaker and more bespoke process than all parties would like it to be. I think the discourse around this could be much improved by people taking the time to understand these complexities and why they pose a challenge to groups with limited engineering resources (like PyPI).