- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 207
Labels
enhancementNew feature or requestNew feature or request
Description
Hello!
First, thanks for this fantastic project - it’s a great help to the community and ecosystem at large.
I would like to suggest adding artifact attestations to the releases.
This would enable supply chain verification for these builds, and provide a layer of validation above just verifying the signature.
it’s pretty simple to add: just a single step, with no configuration or changes required in the binary itself.
what do you think?
martsa1
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Activity
zanieb commentedon Oct 8, 2024
Yeah these seem reasonable, were you interested in contributing this?
orf commentedon Oct 8, 2024
Add build attestations. Closes astral-sh#343
chludwig-haufe commentedon Dec 16, 2024
I see there is an open PR #371, but no further activity. Is there anything blocking the creation of the attestations?
Since I didn't see this mentioned in the documentation: How is the integrity of the Python sources and dependencies used in the build verified?
indygreg commentedon Dec 16, 2024
We pin and verify the sha256 and file size of all downloaded assets. See downloads.py.
zanieb commentedon Dec 16, 2024
@chludwig-haufe there's a blocking comment at #371 (comment)
orf commentedon Dec 16, 2024
Yep! I have this PR in my backlog, but some personal stuff has come up.
We should indeed only attest on main (or anything that actually publishes), adding the relevant
if:
blocks should be all that is needed.Add support for build attestations (#481)
zanieb commentedon Jan 15, 2025
I presume we need to attest the artifacts in
.github/workflows/release.yml
too? We create several derived artifacts.chludwig-haufe commentedon Jan 17, 2025
Please pardon my ignorance (I am not an active user of GitHub actions) – but Verifying artifact attestations with the GitHub CLI made me assume I could verify the integrity of a downloaded package as follows:
What am I missing?
zanieb commentedon Jan 17, 2025
The
-install_only
archives are derived, as I mentioned in #343 (comment)zanieb commentedon Jan 17, 2025
Let's just re-open this until we reach a point where these are validated as functional. cc @samypr100
chludwig-haufe commentedon Jan 18, 2025
Ah, I didn't make the connection that your comment referred to installable packages, too. I had assumed you meant SBOMs and similar metadata. (I am obviously not familiar with your build pipeline.) Thanks for the clarification.
chludwig-haufe commentedon Jan 19, 2025
I can verify, e..g.,
cpython-3.10.16+20250115-aarch64-apple-darwin-pgo+lto-full.tar.zst
.On the other hand, the verification of
cpython-3.10.16+20250115-aarch64-unknown-linux-gnu-lto-full.tar.zst
fails with a 404.Looking at .github/workflows/linux.yml, I suspect the former artifact is generated by
build-1
and the latter bybuild-0
:build-1
includes a "Generate Attestation" step in line 326, whereasbuild-0
has no such step.Build attestations improvements (#501)
samypr100 commentedon Feb 14, 2025
@chludwig-haufe can you try again on the latest release?
chludwig-haufe commentedon Feb 14, 2025
I downloaded and successfully verified all(?) 564 artifacts matching the shell pattern
cpython*.tar.{gz,zst}
- looks good!Thanks!
zanieb commentedon Feb 14, 2025
Thank you!