You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by "kobihikri (via GitHub)" <gi...@apache.org> on 2026/07/28 22:42:36 UTC

[PR] ci: attach provenance and SBOM attestations to the published MCP image [shardingsphere]

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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] ci: attach provenance and SBOM attestations to the published MCP image [shardingsphere]

Posted by "kobihikri (via GitHub)" <gi...@apache.org>.
kobihikri commented on PR #39263:
URL: https://github.com/apache/shardingsphere/pull/39263#issuecomment-5112411004

   **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, `docker/build-push-action` adds provenance attestations with `mode=max` by default — [Docker's documentation](https://docs.docker.com/build/ci/github-actions/attestations/) states it plainly: *"Public repos: provenance attestations with `mode=max` are automatically added"*. I checked published images and they do already carry attestation manifests. So the `provenance: mode=max` line in my diff makes existing behaviour **explicit**; it does not add anything new.
   
   **The SBOM is genuinely new.** That part stands — the same page says *"SBOM attestations aren't automatically added to the image"*, and `sbom: true` is what enables them.
   
   I also wrote in the caveats that `provenance: true` gives "a smaller record". That is wrong as well: `true` resolves to max on a public repo, and the smaller setting is `provenance: mode=min`.
   
   **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.
   


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] ci: attach provenance and SBOM attestations to the published MCP image [shardingsphere]

Posted by "terrymanu (via GitHub)" <gi...@apache.org>.
terrymanu merged PR #39263:
URL: https://github.com/apache/shardingsphere/pull/39263


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org