ci: attach provenance and SBOM attestations to the published image - #3463
Conversation
|
hi @kobihikri thanks for the contribution, could you sign the CLA please? |
|
Correction — I got a fact wrong in this PR, and I would rather flag it myself than let it sit. I wrote that the pushed manifest "carries no provenance or SBOM attestation". That is half wrong, and the wrong half matters. Provenance is already there. For public repositories, The SBOM is genuinely new. That part stands — the same page says "SBOM attestations aren't automatically added to the image", and I also wrote in the caveats that So the honest description of this PR is: it adds an SBOM attestation, and pins the provenance mode explicitly instead of relying on the default. Both are still defensible — an explicit line means the behaviour will not change quietly if the default ever does — but it is a smaller change than my description implied, and you should judge it on that basis rather than on what I originally wrote. Happy to retitle and rewrite the description accordingly, or to close this if the SBOM alone is not worth the diff to you. Either is fine — just say which and I will act on it. Apologies for the inaccuracy. It was caught by a maintainer reviewing the same change on another project, and they were right to. |
all good, we just need you to sign the CLA |
|
CLA is signed — the check is green now. Thanks for your patience with it, and for taking the correction without fuss. One standing offer, since it's easy to lose in the thread: the PR title and description still describe this as adding provenance and SBOM, which — per my correction above — overstates it. The accurate framing is "adds an SBOM attestation; pins the provenance mode that's currently implicit." If you'd like, I'll rewrite the title and body to say that before you merge, so the claim doesn't land in the merge commit and changelog overstating what changed. Say the word and it's done in a minute; otherwise I'll leave it exactly as it is. |
Hi, and thanks for Puter.
.github/workflows/docker-image.yamlpublishes the image toghcr.ioon tag, but the pushed manifest carries no provenance or SBOM attestation. Someone pulling it has no way to check that it was built by this workflow, from this repository, at that tag.For Puter that seemed worth raising because the image is the product as far as a self-hoster is concerned — people run it to host their own files and desktop, so the container is holding user data directly rather than sitting behind another distribution step that might vouch for it.
The change is two lines on the build step:
BuildKit attaches the attestation to the image manifest, so it travels with the image to GHCR without any extra plumbing — and importantly no permissions change is needed. Nothing has to gain
id-token, and your existingcache-from/cache-tosetup is untouched.Consumers can then verify with:
Two caveats worth knowing:
mode=maxrecords the full build including build args. Usually right for a public image;provenance: truegives a smaller record if any build arg has ever been sensitive.No SLSA level claimed; the attestation is what BuildKit produces.
Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow myself.