[pyos meta repo] Use GitHub Artifact Attestations

[blink1073]

GitHub now has full support for Artifact Attestations: https://github.blog/changelog/2024-06-25-artifact-attestations-is-generally-available/

The feature supersedes our usage of SigStore (#156), since it uses SigStore under the hood and has built-in support in the GitHub API/cli, e.g. gh attestation verify PATH/TO/ARTIFACT -o myorganization.

I am happy to make this change if there is agreement.

cc @webknjaz

[webknjaz]

Either that, or the official action. Keep the old job for making releases, perhaps reduce its privileges and add a new job with new privileges.

I actually filed an issue to update this in PyPUG yesterday, too.

The upload attestations will be built into the publish action once that work is completed, by the way.

[blink1073]

By official action do you mean actions/attest-build-provenance or sigstore/gh-action-sigstore-python?

You're saying it might get folded into gh-action-pypi-publish?

[blink1073]

As of https://github.com/pypa/gh-action-pypi-publish/releases/tag/v1.11.0, sigstore attestations enabled by default. pypa/gh-action-pypi-publish#288 is for adding them to GitHub Attestations as well.

[webknjaz]

By official action do you mean actions/attest-build-provenance or sigstore/gh-action-sigstore-python?

Oh, I missed this question. I think I meant pypi-publish back then.

You're saying it might get folded into gh-action-pypi-publish?

Kind of. I want to try uploading the same attestations that are sent to PyPI, to GitHub as well. However, the difference with actions/attest-build-provenance is that technically GH advertises that theirs is for “build provenance” and ours is for “upload provenance”. This is because pypi-publish does not know where your dists are coming from — you might've built them elsewhere and configured GHA to download them into the job from S3 or some other place + publish from there. So within the action we know that we “sign what's published”, but we don't know if we “sign what's built within the same workflow”. As a user, you know what you configured, so you could say that this is build provenance as well.

What I dislike about actions/attest-build-provenance is that they demonstrate running it from test/build jobs and setting elevated privileges there. If you're to use it, I'd recommend still going through the GH workflow artifacts route and signing them in a separate job.

Here's an example of doing this + producing SLSA artifacts as well: https://github.com/ansible/awx-plugins/blob/678ea69/.github/workflows/ci-cd.yml#L925-L1115.

[webknjaz]

[...] sigstore/gh-action-sigstore-python?

You're saying it might get folded into gh-action-pypi-publish?

Oh, and yes, pypi-publish attestations do use sigstore under the hood (as does GitHub's attestations action). So we could say that we absorbed this. Although, there might be slight differences. Still, you could probably extract those files since they end up under dist/ on disk, next to the dists, and upload them to GH Releases instead of the manual signing invocation.

[lwasser]

I just submitted and merged a PR that uses the pypa workflow to publish and removes the sigstore signing step. https://github.com/pyOpenSci/pyosMeta/blob/main/.github/workflows/publish-pypi.yml

We were getting a duplication error where sigstore said the files were already there. So, I read that the PYPA action already signs things and I we don't need the sigstore action if we use the pypa action. I am going to try a release now but in theory this should work and we can then close this issue!! (i think). signing is NOT my area of expertise so please correct my logic if this is not correct.