Dockerfile.rego - signature validation does not work with standard keyless Cosign signatures.

[K-Fl]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

I am testing the Dockerfile.rego to validate base-image signatures, and while I did get it working, it required several non-obvious workarounds.
I followed the Docker documentation on image attestation and provenance(https://docs.docker.com/build/policies/examples/) , but was unable to get signature validation working with standard keyless Cosign signatures out of the box. Here is what I had to do to make it work:

• Sign the attestation manifest, not the root digest. Docker Build Policy follows the provenance chain (OCI index → platform manifest → provenance attestation → signature), so a signature on the root digest alone is not sufficient.
• Use Cosign's legacy simplesigning-v1 format with --new-bundle-format=false and --experimental-oci11=true. The default bundle format used by Cosign v3 is not recognized by BuildKit.
• Downgrade to Cosign v2.6.5, because newer versions (e.g. v3.1.3) fail hard on Rekor 409 Conflict responses, whereas v2.6.5 correctly falls back to fetching and verifying the existing log entry.

After applying all of the above, everything works as expected.

It would be great if the signature validation policy could be updated to support the latest Cosign bundle format and root digest signature validation, so that standard keyless signing works without requiring these workarounds.

Expected behaviour

I expect Dockerfile.rego to successfully validate images signed with keyless cosign signatures, signed like this:

                IMAGE_DIGEST_REF="${{ inputs.image }}@${IMAGE_DIGEST}"
                COSIGN_ARGS=(
                  --yes
                  -a sType=image
                  -a stage=${STAGE}
                  -a gitRepo=${{ github.repository }}
                  -a gitRef=${{ github.ref }}
                  -a gitCommitSha=${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || github.sha }}
                  -a ciRunId=${{ github.run_id }}
                  -a ciRunAttempt=${{ github.run_attempt }}
                  -a workflowRef=${{ github.workflow_ref }}
                  -a imageTag=${{ inputs.version_tag }}
                  -a imageDigest=${IMAGE_DIGEST}
                )

                cosign sign "${COSIGN_ARGS[@]}" "${IMAGE_DIGEST_REF}"

Actual behaviour

To get it work I had to signe like this:

                INDEX_JSON="$(docker buildx imagetools inspect --raw "${VERSION_IMAGE}")"
                mapfile -t ATTESTATION_DIGESTS < <(jq -r \
                  '.manifests[] | select(.annotations["vnd.docker.reference.type"] == "attestation-manifest") | .digest' \
                  <<< "$INDEX_JSON" | sort -u)

                if [[ "${#ATTESTATION_DIGESTS[@]}" -eq 0 ]]; then
                  echo "FAIL: no attestation manifests found for ${VERSION_IMAGE}"
                  exit 1
                fi

                for attestation_digest in "${ATTESTATION_DIGESTS[@]}"; do
                  cosign sign \
                    --new-bundle-format=false \
                    --use-signing-config=false \
                    --registry-referrers-mode=oci-1-1 \
                    "${{ inputs.image }}@${attestation_digest}"
                  echo "Signed attestation digest: ${attestation_digest}"
                done

Buildx version

github.com/docker/buildx v0.36.1

Docker info

Builders list

docker buildx ls 
NAME/NODE             DRIVER/ENDPOINT                                     STATUS    BUILDKIT   PLATFORMS
policytest*           docker-container                                                         
 \_ policytest0        \_ unix:///Users/kjetil.floisand/.rd/docker.sock   running   v0.32.2    linux/amd64 (+2), linux/arm64
default               docker                                                                   
 \_ default            \_ default                                         running   v0.30.0    linux/amd64 (+2), linux/arm64
rancher-desktop       docker                                                                   
 \_ rancher-desktop    \_ rancher-desktop                                 running   v0.30.0    linux/amd64 (+2), linux/arm64

Configuration

FROM ghcr.io/MY-ORG/test-sign.image:fb3014b11127-SNAPSHOT

package docker

default allow := false

allow if input.local

allow if {
  some sig in input.image.signatures
  trusted_github_builder(sig.signer)
}

trusted_github_builder(signer) if {
   input.image.hasProvenance
   signer.certificateIssuer == "CN=sigstore-intermediate,O=sigstore.dev"
   signer.issuer == "https://token.actions.githubusercontent.com"
   startswith(signer.buildSignerURI, "https://github.com/MY_ORG/image-actions/.github/workflows")
   signer.runnerEnvironment == "github-hosted"
}
decision := {
   "allow": allow
}

Build logs

Additional info

No response

[tonistiigi]

Sign the attestation manifest, not the root digest. Docker Build Policy follows the provenance chain (OCI index → platform manifest → provenance attestation → signature), so a signature on the root digest alone is not sufficient.

This is expected. We check the signature of provenance attestation (and that attestation pointing to the image manifest). Just checking signature of manifest does not prove how the image was produced or that any of the fields from the attestations are trustworthy.

Use Cosign's legacy simplesigning-v1 format with --new-bundle-format=false and --experimental-oci11=true. The default bundle format used by Cosign v3 is not recognized by BuildKit.
Downgrade to Cosign v2.6.5, because newer versions (e.g. v3.1.3) fail hard on Rekor 409 Conflict responses, whereas v2.6.5 correctly falls back to fetching and verifying the existing log entry.

This should not be the case. Give us some example images and the commands you used to produce them. You can also use https://github.com/moby/policy-helpers test cli directly to see how signatures are parsed and verified.

[K-Fl]

Signing the provenance attestation makes sense.

I understand that you need an example. I’ll need to put together a new workflow for this, as my current setup is spread across multiple repositories.

Hopefully, it will be ready early next week.

[K-Fl]

@tonistiigi I’ve created a demo repository on GitHub: https://github.com/K-Fl/docker-build-demo.

It contains two workflows:

• A legacy signing workflow that works.
• A new workflow using the OCI bundle format that does not work.

The only difference between them should be the version of cosign used and how the input to cosign is formatted at signing.

[tonistiigi]

The difference seems to be that your old referrers have:

https://oci.dag.dev/?referrers=ghcr.io/k-fl/git-example-base@sha256:6701e6e184dea144b7e5537bbd5a011b46f3504df147f255b78540707fa4d897

"artifactType": "application/vnd.dev.cosign.artifact.sig.v1+json",

While new have:
https://oci.dag.dev/?referrers=ghcr.io/k-fl/git-example-base@sha256:56723354cbccff9fa7aedd51c8e7f8b3f0a321519d07ab9c2b77fd66fb53e375

"artifactType": "application/vnd.oci.empty.v1+json",

That is incorrect.

For new bundle format you should have:

https://oci.dag.dev/?referrers=moby/buildkit@sha256:d13f03d347d55b25cee9c2dd9241f4a159d4200d634a6b6b7963b1aa1a66b44b

"artifactType": "application/vnd.dev.sigstore.bundle.v0.3+json",

Will try to understand if this is coming from some Github registry issue or cosign behavior.

[crazy-max]

I took another look at this and I think the failure is caused by old Cosign/go-containerregistry fallback referrers metadata, not by BuildKit requiring legacy simple signing.

A couple of points:

1. Signing the attestation manifest is expected. BuildKit policy verification follows the provenance chain and verifies the provenance attestation signature, not just a signature on the root image digest. The resolver path is roughly image index -> platform manifest -> BuildKit attestation manifest -> signature referrer:

   • https://github.com/moby/policy-helpers/blob/856be88baec46ecaa01f4d30676e48d14ccffa0b/image/resolve.go
   • https://github.com/moby/policy-helpers/blob/856be88baec46ecaa01f4d30676e48d14ccffa0b/verifier.go

2. The policy helper already knows both the legacy simple signing artifact type and the new Sigstore bundle v0.3 artifact type:

   • application/vnd.dev.cosign.artifact.sig.v1+json
   • application/vnd.dev.sigstore.bundle.v0.3+json

3. In your GHCR repro, the suspicious part is the referrers descriptor, not necessarily the actual signature manifest.

   Old/simple-signing case:
   https://oci.dag.dev/?referrers=ghcr.io/k-fl/git-example-base@sha256:6701e6e184dea144b7e5537bbd5a011b46f3504df147f255b78540707fa4d897

   This has:

   "artifactType": "application/vnd.dev.cosign.artifact.sig.v1+json"

   New bundle case:
   https://oci.dag.dev/?referrers=ghcr.io/k-fl/git-example-base@sha256:56723354cbccff9fa7aedd51c8e7f8b3f0a321519d07ab9c2b77fd66fb53e375

   This has:

   "artifactType": "application/vnd.oci.empty.v1+json"

   That is the bad part. For a Sigstore bundle v0.3 signature, the referrer descriptor should be:

   "artifactType": "application/vnd.dev.sigstore.bundle.v0.3+json"

   The actual signature manifest behind the bad descriptor looks like a proper bundle manifest:
   https://oci.dag.dev/?image=ghcr.io/k-fl/git-example-base@sha256:c2ae5727e0ffb6c84fdd63f2eef2d8a85033ab6248e4bfdb352eb0de3129edae

4. This matters mostly on GHCR because it appears to use the fallback referrers tag path for this case. Docker Hub supports native referrers, so a Docker Hub test can work without exercising the fallback tag behavior:
   https://oci.dag.dev/?referrers=docker.io/dockereng/github-builder-test@sha256:a581115653d46f30de31080792f59d23440586751fdf7891c6fa6bbc78c0a336

The fallback descriptor issue looks like this go-containerregistry bug/fix:
google/go-containerregistry#2269

Before that fix, the fallback referrers descriptor could use the signature manifest config media type, which is how you end up with:

"artifactType": "application/vnd.oci.empty.v1+json"

The fixed code uses the pushed manifest's top-level artifactType when present:
https://github.com/google/go-containerregistry/blob/53f7e39e15bfd6aeea6a5f733ee1a8fcf54c15cf/pkg/v1/remote/write.go

Cosign version mapping:

• Cosign v3.0.3 uses github.com/google/go-containerregistry v0.20.7:
  https://github.com/sigstore/cosign/blob/8e2858f2d4d78ddb6e2e3a518cc3d2df27991e2e/go.mod#L23

• Cosign v3.0.6 uses github.com/google/go-containerregistry v0.21.3:
  https://github.com/sigstore/cosign/blob/77891cd80a8f2bac1a2bf2f37f2e6005df38e51a/go.mod#L23

• Cosign v3.1.2 and v3.1.3 use github.com/google/go-containerregistry v0.21.7:
  https://github.com/sigstore/cosign/blob/193d2153431f8bb0d945a4c1ee721872f73add67/go.mod#L23
  https://github.com/sigstore/cosign/blob/11926fa5bbbbde47e88fc006b625a17769b743b2/go.mod#L23

Your failing sign-new-oci-bundle-format run appears to have installed Cosign v3.0.3, not v3.1.3:
https://github.com/K-Fl/docker-build-demo/actions/runs/31792103800/job/94741104045#step:4:257

The workflow also installs Cosign without pinning the release:
https://github.com/K-Fl/docker-build-demo/blob/413de197b04b78dc56e3ab266f3821d6a8b0d0b5/.github/workflows/sign-new-oci-bundle-format.yaml#L57-L58

Could you retry with Cosign pinned to v3.1.3?

- name: Install cosign
  uses: sigstore/cosign-installer@v4.1.0
  with:
    cosign-release: v3.1.3

Then sign the attestation manifest the same way, without forcing --new-bundle-format=false or --use-signing-config=false.

If this still fails with pinned v3.1.3, please share the new oci.dag.dev/?referrers=ghcr.io/...@<attestation-digest> link. The key thing to check is whether the GHCR fallback referrers descriptor now says:

"artifactType": "application/vnd.dev.sigstore.bundle.v0.3+json"

instead of:

"artifactType": "application/vnd.oci.empty.v1+json"

[K-Fl]

Fantastic, that worked! Pinning the Cosign version was the solution.

I think I had tried pinning it to v3.1.3 before, but I probably only signed the root digest then.

Thank you so much! 🙂