ci: add artefact attestation (using GitHub / SigStore) #1267
Conversation
|
I'm not sure how to e2e test this prior to a release (and particularly pre-merge) 😞. I've verified that it properly generates the attestations, but the actual uploading with the test publish script doesn't work since we don't have access to that account. It works with totally different packages, but that's not really testing this specific PR, just the action. Maybe we could publish a 2.15.0.dev0 to verify and then yank that? Not ideal, but this is the purpose of test.pypi.org... |
|
Note: an alternative here would be to go for higher level SLSA, probably with slsa-github-generator. It's better but more complex. My feeling is that we're better off starting with the simpler GitHub-native attestation and potentially improving that later (maybe based on what the Canonical security team prefers). The PR doesn't add SBOM generation as part of the workflow (you can get one from the dependencies page, of course). I'm not sure whether an SBOM would really add anything to the source tarball, and I'm not sure whether it's worth adding just for the wheel. My feeling is to wait to see whether there ends up being a Canonical policy on this. If we do generate an SBOM then we'd want to attest that as well, of course. |
This PR adds [artefact attestation](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account). The `test-publish` workflow is also updated to use the `build` backend, which was missed when the main script was migrated. Annoyingly, [we are still waiting for access to the operator package on test.pypi.org](pypi/support#3349).
This PR adds [artefact attestation](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account). The `test-publish` workflow is also updated to use the `build` backend, which was missed when the main script was migrated. Annoyingly, [we are still waiting for access to the operator package on test.pypi.org](pypi/support#3349).
This PR adds artefact attestation to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account).
The
test-publishworkflow is also updated to use thebuildbackend, which was missed when the main script was migrated. Annoyingly, we are still waiting for access to the operator package on test.pypi.org.