gh-action-pypi-publish
gh-action-pypi-publish copied to clipboard
pypa
[TODO] Explore uploading attestations to GitHub as well
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.
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).
I haven't found a way to feature-test. So it'd probably be an upload attempt with error suppression...
I haven't found a way to feature-test. So it'd probably be an upload attempt with error suppression...
Makes sense to me :slightly_smiling_face:
@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.
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.
Good idea! Outputs are limited to 1MB, but they should be well below that.
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.
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.)
@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?
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.)
Hi there. I would just like to +1 this idea. I would like it too. Thanks. 😸
