Yeah these seem reasonable, were you interested in contributing this?

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?

We pin and verify the sha256 and file size of all downloaded assets. See downloads.py.

@chludwig-haufe there's a blocking comment at #371 (comment)

@chludwig-haufe there's a blocking comment at #371 (comment)

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.

I presume we need to attest the artifacts in .github/workflows/release.yml too? We create several derived artifacts.

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:

$ curl -LO https://github.com/astral-sh/python-build-standalone/releases/download/20250115/cpython-3.10.16+20250115-aarch64-apple-darwin-install_only.tar.gz
$ export GH_TOKEN="GitHub personal access token w/ read privileges"
$ gh attestation verify cpython-3.10.16+20250115-aarch64-apple-darwin-install_only.tar.gz -R astral-sh/python-build-standalone
Loaded digest sha256:21dba90e7a0b879fdc475411fc8c39e0567c6f5c92112956b63de7f83ee433ad for file://cpython-3.10.16+20250115-aarch64-apple-darwin-install_only.tar.gz
✗ Loading attestations from GitHub API failed

Error: failed to fetch attestations from astral-sh/python-build-standalone: HTTP 404: Not Found (https://api.github.com/repos/astral-sh/python-build-standalone/attestations/sha256:21dba90e7a0b879fdc475411fc8c39e0567c6f5c92112956b63de7f83ee433ad?per_page=30)

What am I missing?

The -install_only archives are derived, as I mentioned in #343 (comment)

Let's just re-open this until we reach a point where these are validated as functional. cc @samypr100

The -install_only archives are derived, as I mentioned in #343 (comment)

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.

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 by build-0: build-1 includes a "Generate Attestation" step in line 326, whereas build-0 has no such step.

@chludwig-haufe can you try again on the latest release?

I downloaded and successfully verified all(?) 564 artifacts matching the shell pattern cpython*.tar.{gz,zst} - looks good!

Thanks!

Thank you!