[znerol2]

Summary

docs/DEVELOPMENT-AND-BUILD-RULES.md still said cosign signing was "not yet wired" and would gate pulls. That's out of date.

• Each release already carries a GitHub build-provenance attestation on its index digest, a signed record of the workflow, commit and repository that built it. The section now says so, and shows how to verify a release with gh attestation verify.
• The cluster checks neither signatures nor attestations when it pulls an image, so a separate cosign signature would add nothing yet.
• Cosign signing and a pull-time admission policy stay open as an option for a lane that must refuse unverified images.

Decision (maintainer, 2026-11-08): the provenance attestation satisfies dmfdeploy/dmfdeploy#14 for now.

Check

gh attestation verify oci://ghcr.io/dmfdeploy/dmf-cms:0.41.0 --repo dmfdeploy/dmf-cms exits 0.

Closes dmfdeploy/dmfdeploy#14

[lkirc]

The new guidance overstates its coverage.

• docs/DEVELOPMENT-AND-BUILD-RULES.md:550: Scope this to releases published by the current attesting workflow (or document the first attested version). v0.39.0 predates .github/workflows/release.yml, so historical <VERSION> values do not have the workflow-created provenance attestation that the unqualified verification command promises.

[znerol2]

Thanks, good catch. Fixed in 0d8fe9f: the section now scopes the attestation to releases the release workflow published and names 0.40.1 as the first. I checked each release with gh attestation verify: 0.38.0, 0.39.0 and 0.40.0 fail; 0.40.1, 0.40.2 and 0.41.0 pass.

[lkirc]

Approved. The current head resolves the prior attestation-scope concern: it limits the guidance to workflow-published releases and documents 0.40.1 as the first attested release.