Latest container images aren't signed

[jordi-t]

It appears that this image isn't signed:

cosign verify ghcr.io/cloudnative-pg/postgresql@sha256:6d41466de5d43a80544cc5768038b2de964ae5b1d725683c03c5d9f81fdc2e43 --certificate-identity-regexp="^https://github.com/cloudnative-pg/postgres-containers/" --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

Error: no signatures found
error during command execution: no signatures found

The same goes for all other images built 3 days ago. I guess it has something to do with this failed workflow.

This is a bit problematic for environments which are automatically validating image signatures through policies, as these will now block pods of CNPG clusters based on these images.

FYI images built 10 days ago actually do contain a signature.

[dosubot]

Hi @jordi-t! I'm Dosu and I’m helping the postgres-containers team.

You are correct—the latest images (including the one you linked) are currently unsigned, and this appears to be related to a recent workflow failure. The signing process for these images is handled by cosign in the GitHub Actions pipeline, and the workflow configuration still includes mandatory signing steps with proper permissions and no recent changes that would intentionally skip signing. This suggests the issue is likely due to a runtime or environment failure during the workflow run, not a configuration change or code update. There is no official communication or workaround published in the repository about re-signing or re-publishing the affected images, and no issues or discussions directly address this problem yet. For now, environments enforcing signature validation will block these unsigned images, and the only available workaround is to use previously signed images until new signed versions are published.
Workflow details and signing steps
Recent workflow and cosign updates

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[jordi-t]

The latest build based on the bake.yml workflow succeeded, but this image is still unsigned.

However, the issue doesn't have anything to do with the bake.yml workflow, as this particular image/tags are built and pushed via the build.yml workflow which runs on a daily basis.

I guess the issue is that the build.yml workflow doesn't contain any signing steps. Would it be possible to add this?

[dosubot]

You're correct—the build.yml workflow currently does not include any image signing steps, which is why images built and pushed by it remain unsigned reference. Adding signing is technically feasible and can follow the pattern used in bake.yaml reference.

To add signing to build.yml, you would need to:

1. Install cosign (using sigstore/cosign-installer).
2. Adjust permissions for the relevant job to include id-token: write (required for OIDC-based signing).
3. After pushing images, collect the image digests.
4. Run cosign sign --yes on each image digest.

Both workflows use GitHub Actions, so the setup is transferable—just ensure the permissions and environment match what’s in bake.yaml. There’s no documentation or policy in the repo that would prevent this, but if there are any org-level restrictions, those would need to be checked separately.

If you want a concrete example, the relevant steps from bake.yaml are:

• Install cosign:

  - name: Install cosign
    uses: sigstore/cosign-installer@v3

• Set permissions:

  permissions:
    id-token: write
    contents: read
    packages: write

• Sign images after pushing:

  - name: Sign images
    run: |
      cosign sign --yes <image>@<digest>

Let me know if you want a more detailed snippet or have questions about integrating this!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[sxd]

Hi @jordi-t

As @dous pointed and you already find out, those images are not signed and were never signed from the beginning, because we plan to actually discard those images in favor of the new process, now, you can use the new images or you can create a PR to add the signature =)

For now closing since this is expected

[jordi-t]

Hi @sxd

Thanks for taking the time to comment, all clear 👍 We'll indeed start adopting the standard/minimal images as these are always signed. I wouldn't mind creating a PR for the other build process, but considering this process is pretty much deprecated it wouldn't be worth the effort imho - it would only give people more reason not to move towards the standard/minimal images ;)

However, I guess the current docs could be a bit more clear on this, as it's currently mentioned that signing is done for all operand images: All container images are signed.... Perhaps better to mention that signing only applies to minimal/standard images? Same goes for these docs.

If you'd like I can create an issue / PR for this?

[sxd]

@jordi-t yes please create a PR it will be awesome if you do it today so we can included in tomorrow release =D

[jordi-t]

@sxd I've created both PR's, hopefully in time for tomorrow's release ;)