Cosign architecture-specific images too?

[pjonsson]

If I regctl image copy --referrers ghcr.io/cloudnative-pg/postgresql:18.4-standard-trixie private.goharbor.instance.com/cloudnative-pg/image:18.4, the top level view appears like this with a green checkmark:

but if I click the "view this OCI index's artifact list" I get this:

so the architecture-specific images aren't signed. This means I can't enable the feature in Harbor that prevents downloads of non-cosigned images since the images from this repository aren't signed recursively.

Is there a reason only the top manifest is signed, or would it be possible to add --recursive to the cosign sign command that produces the release images in this organization?

[dosubot]

Hi @pjonsson! I'm Dosu and I'm helping the CloudNativePG team.

You're right — the --recursive flag is not currently used with cosign sign anywhere in this repository. The signing commands only sign the top-level manifest list by digest, not the individual architecture-specific images underneath it.

There are two places where cosign sign is called:

1. In the build workflow (bake_targets.yml):

   echo "${BUILD_METADATA}" | \
     jq '.[] | (."image.name" | sub(",.*";"" )) + "@" + ."containerimage.digest"' | \
     xargs cosign sign --yes

2. In the image promotion action (copy-images/action.yml):

   cosign sign -t 5m --yes ${images}

Neither uses --recursive. I didn't find any prior issues or PRs discussing recursive signing, so this appears to be a new request. Adding --recursive to these commands should sign all the architecture-specific images within the manifest list as well, which would resolve the Harbor content trust issue you're describing.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.