v0.37.1 Darwin ARM64: published executable checksum differs from provenance subject

[saifulazadrana]

Hello Buildx maintainers,

I found a metadata consistency mismatch for buildx-v0.37.1.darwin-arm64 and would appreciate clarification on the intended verification path.

The release API and the exact filename entry in checksums-signed.txt agree on this executable SHA-256:

c3cbbc820d578b0aa8158dd62ef1af25a0c8a75ef53331dbe4e219471e1dbe8c

However, buildx-v0.37.1.darwin-arm64.provenance.json contains one subject with that exact filename and a different SHA-256:

efe594940f5eb29dc1157db9a1c666e829eee75609378aecc15c4bcb430d4102

Both downloaded metadata bodies matched their own API-declared sizes and hashes:

Metadata asset	Bytes	SHA-256
checksums-signed.txt	386	7b481bf1de31986a1f08dfe4c08cb9c6bd393999b8fc4beeef3c10bc79db591d
Darwin ARM64 provenance	55,617	dbcdd88c199894c5cd557f80bf861edac9bcbe8db71ced424395491eff6af9a6

The checksum file contains exactly one matching executable-name record. The provenance uses in-toto Statement v1 and SLSA provenance v1. All three assets were listed as uploaded.

Separately, the checksum asset’s API media type was text/plain; charset=utf-8; the provenance asset’s API media type was application/json, while its downloaded response was application/octet-stream. These transport details do not explain the digest difference.

The inspected v0.37.1 build workflow explicitly excludes Darwin/Windows records from checksums.txt and removes their provenance.sigstore.json bundles. Its pinned reusable workflow signs build provenance.

Those exclusions appear deliberate, but the inspected sources did not establish what changed the executable digest. I am not assuming macOS signing explains it.

Could you clarify:

1. What exact artifact does this provenance subject represent, and is this mismatch expected?
2. Is there official, release-specific evidence verifiably linking these two exact digests?
3. Alternatively, where is qualifying provenance whose subject directly matches the published executable’s c3cbbc…1dbe8c digest?

This was a metadata-only investigation. No executable was downloaded or run, and no signature-verification claim is being made. The verification requirement remains exact digest agreement; unequal hashes have not been accepted as equivalent.

Thank you.

[crazy-max]

The digest difference is expected. The provenance describes the binary produced by the public build workflow. Darwin binaries are subsequently signed and notarized in an internal workflow, and the signed binaries replace the original release assets. Signing changes the executable bytes and therefore its digest.

For the final Darwin binary, use checksums-signed.txt to check its checksum and verify its Apple code signature and notarization for authenticity. The checksum manifest itself is not cryptographically signed. We currently do not publish SLSA provenance for the final signed binary or a public attestation linking the two digests, so the original provenance cannot satisfy the exact-digest verification requirement you describe.

I opened #4102 to document this behavior and the verification limitations in the README.

[saifulazadrana]

Thanks for explaining the Darwin signing/notarization workflow and provenance limitation.

For the standalone buildx-v0.37.1.darwin-arm64 release asset, could you document:

1. The authoritative expected Apple Team ID, Developer ID certificate class, and signing identifier or designated requirement consumers should enforce. Please include any release-specific differences or certificate-rotation policy.
2. The supported consumer commands and success criteria for verifying both that expected identity and notarization on the exact standalone executable distributed through GitHub, without launching it.
3. The supported macOS versions, any required container or separate ticket, and how offline, unavailable, or revoked-status results should be handled.

We will not infer Buildx’s signer from Docker Desktop or adopt the identity reported by an untrusted candidate binary. Please point to an official declaration establishing the expected identity independently.

We understand these checks would establish a different assurance from final-executable SLSA provenance; they would not resolve the missing attested link between the two digests.