verify should support code forges for more robust assertions

[philpennock]

Description

Asking end-users to construct regular expressions to match against a URL for the full spec of a release of a project, while allowing the project to issue new releases, or switch branch names, or whatever else, is asking for verification mistakes.

If the UX for verifying signatures is to use cosign, then cosign should probably reconsider the OID deprecation of the GitHub attributes and provide a UX around verifying identities.

(I'm being careful around "forge" as a shorthand for "code hosting repository", because --issuer-forge sounds like forge in the sense of "forgery", so I'm using codeforge here to provide the limited service agnosticism.)

So instead of:

cosign verify-blob \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github\.com/goreleaser/goreleaser-pro-internal/\.github/.+' \
  [...]

cosign might consider:

cosign verify-blob --issuer-codeforge github:goreleaser/goreleaser-pro-internal [...]

and then maintain an internal mapping of forge names to OIDC issuers, and which attributes make sense to use by default. The self-hosted options can still be supported by explicit --certificate-oidc-issuer and probably should not be supported by the simplified UX, since the whole model here is that we're encouraging people to trust OIDC for claims from a well-run code forge.

[znewman01]

Thanks for filing this.

Asking end-users to construct regular expressions to match against a URL for the full spec of a release of a project, while allowing the project to issue new releases, or switch branch names, or whatever else, is asking for verification mistakes.

Agreed, and thanks for the proposed UX which is much nicer than what we have now.

Related: #2691 I'm probably going to mark this a dupe of that, but inline some of the ideas from this thread; expect a response there as well.