Skip to content

docs(release): describe the provenance attestation instead of planned cosign signing #217

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dmf-cms-automerge merged 2 commits into from
Nov 9, 2026
Merged

docs(release): describe the provenance attestation instead of planned cosign signing #217

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4e4373f
docs(release): describe the provenance attestation instead of planned…
znerol2 Nov 9, 2026
0d8fe9f
docs(release): name the first release that carries a provenance attes…
znerol2 Nov 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 14 additions & 4 deletions docs/DEVELOPMENT-AND-BUILD-RULES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -545,10 +545,20 @@ org.opencontainers.image.source = https://github.com/dmfdeploy/dmf-cms
`docker inspect <image>` exposes them; useful for forensics when a pod is on
a tag you don't recognize.

### Signing (deferred)

Cosign signing is not yet wired. When it is, `build-image.sh` gains a `cosign sign`
step after `docker push` and the cluster gates pulls on a verified signature.
### Provenance and signing

Every release that the release workflow above publishes carries a GitHub
build-provenance attestation on its index digest. It is a signed record of the
workflow, commit and repository that built that digest. The first attested release
is 0.40.1; 0.39.0 and earlier were published before the workflow and have no
attestation. To check a release from 0.40.1 on, run
`gh attestation verify oci://ghcr.io/dmfdeploy/dmf-cms:<VERSION> --repo dmfdeploy/dmf-cms`.

The cluster does not check signatures or attestations when it pulls an image. A
separate cosign signature would add nothing until something enforces it, so the
release does not sign with cosign. For a lane that must refuse unverified images,
both stay open: a cosign signature, and an admission policy that checks the
signature or the attestation at pull time.

---

Expand Down
Loading