search

pyOpenSci / pyosMeta

A package that updates pyOpenSci contributor and package metadata on our website
BSD 3-Clause "New" or "Revised" License
6 stars 18 forks source link

[pyos meta repo] Use GitHub Artifact Attestations #165

Open blink1073 opened 5 months ago

blink1073 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 3 weeks ago

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

webknjaz commented 3 weeks ago

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 commented 3 weeks ago

[...] 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.