From 4e4373f6526708b40b57c50842389f07aeb54381 Mon Sep 17 00:00:00 2001 From: znerol2 <6800371+znerol2@users.noreply.github.com> Date: Mon, 9 Nov 2026 08:04:51 +0100 Subject: [PATCH 1/2] docs(release): describe the provenance attestation instead of planned cosign signing The build rules still said cosign signing was not wired and would gate pulls. Releases already carry a GitHub build-provenance attestation on the index digest, and nothing in the cluster checks signatures at pull time, so a cosign signature would add nothing yet. Say what exists, how to verify it, and that cosign and pull-time enforcement stay open for a lane that must refuse unverified images. Closes dmfdeploy/dmfdeploy#14 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com> --- docs/DEVELOPMENT-AND-BUILD-RULES.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/DEVELOPMENT-AND-BUILD-RULES.md b/docs/DEVELOPMENT-AND-BUILD-RULES.md index acf9885..dbcddb0 100644 --- a/docs/DEVELOPMENT-AND-BUILD-RULES.md +++ b/docs/DEVELOPMENT-AND-BUILD-RULES.md @@ -545,10 +545,18 @@ org.opencontainers.image.source = https://github.com/dmfdeploy/dmf-cms `docker inspect ` 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 carries a GitHub build-provenance attestation on its index digest +(see the release workflow above). It is a signed record of the workflow, commit and +repository that built that digest. To check a release, run +`gh attestation verify oci://ghcr.io/dmfdeploy/dmf-cms: --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. --- From 0d8fe9f182e6824026d013ce499361be746e03f6 Mon Sep 17 00:00:00 2001 From: znerol2 <6800371+znerol2@users.noreply.github.com> Date: Mon, 9 Nov 2026 09:29:21 +0100 Subject: [PATCH 2/2] docs(release): name the first release that carries a provenance attestation The verify command only works for releases the release workflow published. 0.40.1 is the first; 0.39.0 and earlier have no attestation. Refs dmfdeploy/dmfdeploy#14 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com> --- docs/DEVELOPMENT-AND-BUILD-RULES.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/DEVELOPMENT-AND-BUILD-RULES.md b/docs/DEVELOPMENT-AND-BUILD-RULES.md index dbcddb0..d0c293d 100644 --- a/docs/DEVELOPMENT-AND-BUILD-RULES.md +++ b/docs/DEVELOPMENT-AND-BUILD-RULES.md @@ -547,9 +547,11 @@ a tag you don't recognize. ### Provenance and signing -Every release carries a GitHub build-provenance attestation on its index digest -(see the release workflow above). It is a signed record of the workflow, commit and -repository that built that digest. To check a release, run +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: --repo dmfdeploy/dmf-cms`. The cluster does not check signatures or attestations when it pulls an image. A