kobihikri opened a new pull request, #39263:
URL: https://github.com/apache/shardingsphere/pull/39263

   Hi, and thanks for ShardingSphere.
   
   `.github/workflows/release-mcp.yml` publishes 
`ghcr.io/apache/shardingsphere-mcp` on release, but the pushed manifest carries 
no provenance or SBOM attestation. Someone pulling the image cannot check that 
it was built by this workflow, from this repository, at that release.
   
   For an Apache project this tends to carry a little extra weight — downstream 
users often need to show where a component came from as part of their own 
compliance evidence, and an ASF-published image is exactly the kind of artifact 
they will be asked about.
   
   The change is two lines on the build step:
   
   ```yaml
             push: true
             provenance: mode=max
             sbom: true
   ```
   
   BuildKit attaches both to the image manifest, so they travel with the image 
to GHCR. **No permissions change is needed** — nothing has to gain `id-token`, 
and your tag-assembly logic (the `:VERSION` / `:latest` split for 
non-prereleases) is untouched.
   
   Consumers can then check with:
   
   ```
   docker buildx imagetools inspect ghcr.io/apache/shardingsphere-mcp:<version> 
--format '{{ json .Provenance }}'
   ```
   
   Two caveats worth stating: `mode=max` records the full build including build 
arguments, so `provenance: true` gives a smaller record if any have ever 
carried something sensitive; and attestations add an extra manifest to the 
index, which GHCR handles but is worth knowing if a mirror or an internal copy 
step sits in the path.
   
   I have not claimed any SLSA level — the attestation is what BuildKit 
produces, and characterising the overall build against a level is a judgement 
for the project rather than for me.
   
   Disclosure: I used AI assistance to help spot this and prepare the change, 
and I read the workflow myself.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to