Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TODO] Explore uploading attestations to GitHub as well #288

Open
webknjaz opened this issue Nov 5, 2024 · 11 comments
Open

[TODO] Explore uploading attestations to GitHub as well #288

webknjaz opened this issue Nov 5, 2024 · 11 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@webknjaz
Copy link
Member

webknjaz commented Nov 5, 2024

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
Copy link
Member

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
Copy link
Member Author

webknjaz commented Nov 5, 2024

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

@woodruffw
Copy link
Member

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
Copy link
Member Author

webknjaz commented Nov 8, 2024

@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
Copy link
Member

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
Copy link
Member Author

Probably wrap it as a JSON string.

@woodruffw
Copy link
Member

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

@webknjaz
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

webknjaz commented Dec 3, 2024

@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
Copy link
Member

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants