Description
Breakout from #17001.
Attestations are currently tied to Trusted Publishing: to produce an attestation accepted by PyPI, the user must go through a Trusted Publishing flow and use the same machine identity as their Trusted Publisher to sign for the attestation.
This is suitable for many (most?) package maintainers, who already use GitHub, GitLab, etc. to manage and publish their projects. However, not all users can/want to/should use these platforms, and those users should be able to produce attestations as well with the normal API token-authenticated publishing flow.
So, the rough idea: PyPI should also accept publish attestations from email identities, instead of just CI/CD machine identities. This requires a few moving parts:
- We need to determine what the "trusted set" of email identities for a package is: is it the set of verified emails for the maintainers/owners of that project, or the subset that are also listed in distribution metadata, or is it something new?
- Another possibility here would be to have it be opt-in: maintainers can mark their already-verified emails as being eligible for attestations on PyPI, e.g. via a checkbox in the user settings.
- We need to determine an issuer policy for email attestations. Unlike machine identities (which come from an invariant issuer, like GitHub Actions or GitLab CI/CD), email identities can be issued at the OIDC layer by multiple issuers. For example, I can get an OIDC token for my personal email from GitHub's IDP (based on it being a verified email from my account) or from my email provider's IDP (based on it being a real account on their service). The different in "proof" between these issuers is subtle and difficult to communicate to users, so PyPI should be judicious about which ones it supports and how.
Besides those, this should be as simple as accepting the resulting attestations when provided during a non-TP (i.e. manual API token) publishing flow.