PEP 740: Post-deployment tasks

[woodruffw]

The main roadmap for PEP 740 is in #15871; this tracks related items that aren't blockers, but need to be thought about more and/or addressed in the medium-to-long term.

• Support for other attestation types. Right now the "PyPI Publish" and SLSA types are supported, although the SLSA type is currently gated off since nothing is uploading it yet. The latter should be enabled.
• Evaluate additional forms of domain separation in the attestation body. Right now there's a scenario in which a single workflow identity can sign publish attestations for both PyPI and TestPyPI, and those two attestations are indistinguishable (since a publish attestation doesn't currently encode its intended "recipient" index). This leaves open a subset of index poisoning attacks, where an attacker manages to obtain attestations intended for TestPyPI and gets PyPI to serve them instead. @alex and I originally discussed this ~2 years ago and the original approach within Fulcio itself didn't pan out, so it needs to be tackled within the attestation body itself.
  • The solution to this is to encode a domain separator in the attestation payload, which could be as simple as the current OIDC audiences for PyPI and TestPyPI (pypi and testpypi respectively). We have a strong source of timeliness in the form of signed time, so we could add these and then require them in new attestations after a period of adoption.
• Enable attestation support for other Trusted Publisher providers, e.g. GCB and ActiveState. This should be straightforward, just needs tests.

[webknjaz]

• Support for other attestation types. Right now the "PyPI Publish" and SLSA types are supported, although the SLSA type is currently gated off since nothing is uploading it yet. The latter should be enabled.

Is it possible to do this in a job following pypi-upload?

[woodruffw]

• Support for other attestation types. Right now the "PyPI Publish" and SLSA types are supported, although the SLSA type is currently gated off since nothing is uploading it yet. The latter should be enabled.

Is it possible to do this in a job following pypi-upload?

Not at the moment -- in principle we could add a separate upload endpoint/codepath for uploading attestations to an already-uploaded release, but that doesn't exist yet. For the time being, the assumption is that one or more attestations get uploaded with the release itself, so a user who wants to upload a SLSA attestation should put it in their dist/ alongside their publish attestation.

In other words, a dist/ structure like:

dist/
  foo-1.2.3.tar.gz
  foo-1.2.3.tar.gz.publish.attestation
  foo-1.2.3.tar.gz.slsa.attestation

(The interstitial .publish. and .slsa aren't semantically meaningful -- twine just looks for dist.*.attestation).

[webknjaz]

@woodruffw so I'm usually structuring my workflows to do any mutations post initial PyPI publish. That's my point of no return. Besides, the official SLSA automation for GHA is a reusable workflow. So running it before publishing would be a separate job with a hope that dists will get uploaded eventually, which may not happen in case of release rejection. This is my primary motivation for uploading attestations post-release (which could be useful in tandem with the very old request to have draft releases for transactional uploads).

By the way, I've researched a little how the attestations are uploaded to GH: pypa/gh-action-pypi-publish#288.