feat: sign checksums and containers with cosign

[scop]

Refs https://www.sigstore.dev, https://docs.sigstore.dev.

This makes use of cosign's identity-based/keyless mode: https://docs.sigstore.dev/cosign/signing/overview/

I have an example of this in action in my fork (which I've cut down to just the related parts to build and publish)

• Actions job: https://github.com/scop/upcloud-cli/actions/runs/13110600188/job/36573458825
• Release including the cosign related files (checksums.txt-keyless.*): https://github.com/scop/upcloud-cli/releases/tag/v0.0.0
• Docker images with the cosign related assets (sha256-*.sig): https://github.com/scop/upcloud-cli/pkgs/container/upcloud-cli
  • Looks like GH creates an example pull recipe using this signature file to the above packages page (docker pull ghcr.io/.../upcloud-cli:sha256-*.sig). That isn't ideal, but I don't know if it's that much of a concern. I wonder if there's a way to mark some of the images as the default from which this would be generated?

To try and verify the blobs and images in my fork above with cosign, tweak the project and release in the docs recipe accordingly.

Details

project_url=https://github.com/scop/upcloud-cli
release=v0.0.0
cosign verify-blob \
    --certificate-identity ${project_url}/.github/workflows/publish.yml@refs/tags/${release} \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    --certificate ${project_url}/releases/download/${release}/checksums.txt-keyless.pem \
    --signature ${project_url}/releases/download/${release}/checksums.txt-keyless.sig \
    ${project_url}/releases/download/${release}/checksums.txt

project=scop/upcloud-cli
release=v0.0.0
cosign verify \
   ghcr.io/${project}:${release} \
   --certificate-identity https://github.com/${project}/.github/workflows/publish.yml@refs/tags/${release} \
   --certificate-oidc-issuer https://token.actions.githubusercontent.com |
   jq .

Once/if we have a future release out with these changes, I'll send a PR over to aqua-registry to make use of the signatures. After that is out with aqua and mise, installing with them will automatically verify the signatures and we can add a note to our docs about it (assuming we've merged #371 meanwhile).

[scop]

A problem with doing the signatures this way in goreleaser is that when cosign is not running within the GH builder context, it won't be using the GH OIDC provider, and thus in local goreleaser runs it resorts to prompting the user to access signstore using their browser. And it appears that conditionalizing the signing is a goreleaser pro feature.
(BTW the prompt will be only shown in the goreleaser output when running with --verbose (or alternatively we could add output: true to the goreleaser *signs config)).

In that sense, it would perhaps be better to implement the signing in GH workflows proper, rather than in goreleaser (even though it's quite convenient that way).

Setting draft until we've settled on the approach on this.