[TODO] Explore uploading attestations to GitHub as well

[webknjaz]

This is how the official action does this: https://github.com/actions/toolkit/blob/77f247b/packages/attest/src/store.ts#L5-L44.

This is the API endpoint doc: https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#create-an-attestation.

[woodruffw]

Yep, this should be straightforward to do -- the attestation will either need to be uploaded to GH before it's munged into the PEP 740 shape, or re-munged back into a Sigstore bundle for subsequent uploading.

One note: putting things in GH's attestations store also requires attestations: write, which is why I didn't look too closely at it initially for this action -- I didn't want to widen things beyond id-token: write, since that would be painful for users to upgrade to. However, it may be worth it (or something we can feature-test).

[webknjaz]

I haven't found a way to feature-test. So it'd probably be an upload attempt with error suppression...

[woodruffw]

I haven't found a way to feature-test. So it'd probably be an upload attempt with error suppression...

Makes sense to me 🙂

[webknjaz]

@woodruffw it might be a good idea to also explore exposing the signatures to the end-users (maybe, via action outputs?). As in, beyond telling them to scan the dist/ folder for those files. This would let them upload a copy to GH Releases if they want to.

[woodruffw]

Yeah, that's a good idea -- I haven't been 100% sure how to do it since it's a one-many relationship in theory (one dist, potentially multiple attestations), so action outputs become a little hacky. I'll think about that some more.

[webknjaz]

Probably wrap it as a JSON string.

[woodruffw]

Good idea! Outputs are limited to 1MB, but they should be well below that.

[webknjaz]

Yeah, I tend to be wrestling with passing complex data into and out of the actions (like alls-green) for a long time. And I settled on JSON, especially since they have builtin functions available (toJSON()/fromJSON()). The only other option is probably putting things into files.

[woodruffw]

Another aspect of this: the other way around would be useful, i.e. taking SLSA/etc. attestations produced by GitHub's official actions and munging them into the PyPI attestation format.

This should be pretty straightforward to do, especially now that pypi-publish is a composite action: we could have an interstitial uses: whatever/adapt-attestations-to-pypi (or whatever) that performs the conversion.

(That's a bit of a tangent from the original topic here though, so I can file a separate issue for this if desired.)

[webknjaz]

@woodruffw I'm concerned about steering people towards allowing OIDC in test jobs. This wouldn't be a problem with SLSA, I suppose, since it requires using their reusable workflow with is a bunch of separate jobs already. But not sure about other things.
Additionally, I was under the impression that it was not a good idea to sign things too early, before we know that publishing will actually happen (or that it won't fail).
I'm a firm believer that this should be happening post actual release. What are your thoughts on this?

[woodruffw]

I'm concerned about steering people towards allowing OIDC in test jobs.

I might be missing a connection here, but what does this have to do with OIDC in test jobs? This would solely be a way to have GitHub's machinery produce the attestations, rather than the attestations.py script; the top-level constraint that the identity must match a Trusted Publisher would still apply.

Additionally, I was under the impression that it was not a good idea to sign things too early, before we know that publishing will actually happen (or that it won't fail).

I don't think this is a bad thing, per se: it results in "useless" signatures in the sense that they never appear on PyPI, but it doesn't compromise the security of the scheme (since a publish attestation conveys intent, and the intent was to publish, even if the upload fails or rejects the upload).

I'm a firm believer that this should be happening post actual release. What are your thoughts on this?

I think it depends on the kind of attestation 🙂 -- for things like build/publish provenance, IMO it makes sense for them to happen before the release: part of the design here includes signed timestamps, and it would be a red flag to have a release made at time T and its claimant attestation (the thing claiming authentic publishing) to be made at T + N.

On the other hand, third-party attestations (which aren't implemented yet), would probably happen post-release, almost by definition. For these the opposite would hold: having a release at T and a third-party attestation at T - N would suggest collusion between putatively independent entities.

TL;DR: I think build/publish attestations have valuable timeliness properties that only hold/are only meaningfully auditable if they occur before the release appears on PyPI. OTOH, other attestations have valuable timeliness properties in the opposite direction.

(Another reason to have build/publish attestations before the release is "locality": the goal of an attestation is to capture both a signature and a detailed identity, which means performing the attestation as close to the operation it's attesting for as possible.)