@knqyf263 Can I work on this?

If I'm getting this correct, we sign the build artifact in our CI and push it to our Container Registry, and give our end users an option to verify the artifact they downloaded either using our public key or keyless.

Is there anything else you have in mind?

Sounds good!

Hey @knqyf263, so I have worked on something similar at Kyverno and had a query.

The design system for this we followed there was to push the signature as well as the artifact (in our case, DB) in the same CR. The issue we faced there later was that the metrics(number of downloads for the package) weren't accurate anymore as cosign verifications downloaded the .sig file and affected the same.

Hence we later shifted to a separate signatures GHCR signatures

Since, in our case, until now, we are overwriting the image with the same tag on our CR, it does not populate the CR and keeps it clean.
However, a signature is generated based on the hash of the commit hence it would get really populated with the signatures.

Attaching a screenshot for an exact mockup I tried for our trivy-db on my personal GHCR package:

As we can see. for every update and push in the CR, it generates and pushes a new sig file.

Hence, in my opinion, we should create a separate package registry, too, like trivy-db-signatures. Would like to know your thoughts on the same.

Nice catch. It makes sense to have another repository for signatures.