Add support for passing different SignerVerifier LoadOptions

[ret2libc]

Summary

This is a preparation PR for #3271 and it splits some changes required to completely add support for ed25519ph, with the idea of helping the reviewers. It was split from #3479 .

Release Note

• Adds functions SignerFromKeyOptsWithSVOpts, LoadPrivateKeyWithOpts, ValidateAndUnpackCertWithOpts, VerifyImageSignaturesWithOpts, VerifyLocalImageSignaturesWithOpts, VerifyBlobSignatureWithOpts, VerifyImageSignatureWithOpts, VerifyImageAttestationsWithOpts, VerifyLocalImageAttestationsWithOpts, VerifyBlobAttestationWithOpts, VerifyImageAttestationWithOpts, VerifierForKeyRefWithOpts, LoadPublicKeyRawWithOpts, SignerVerifierFromKeyRefWithOpts, PublicKeyFromKeyRefWithOpts.

Documentation

With recent sigstore, we introduced signature.LoadVerifierWithOpts (and other versions for Signer, SignerVerifier). Adding support for ed25519ph would require passing some options around, however cosign is still using signature.LoadVerifier. This PR prepares the cosign codebase to accept LoadOptions and pass them around, without actually changing (yet) any behaviour.

Doing that required adding a lot of *WithOpts functions to avoid breaking other users who may rely on those exported functions. Please let me know if that's a good approach.

Once this is done, we can work on a smaller PR that actually adds supports for ed25519ph and pass the correct extra LoadOptions around.

[ret2libc]

cc @haydentherapper

[codecov]

Codecov Report

Attention: Patch coverage is 60.44776% with 53 lines in your changes missing coverage. Please review.

Project coverage is 36.94%. Comparing base (2ef6022) to head (753bfc0).
Report is 308 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/cosign/verify.go	66.23%	26 Missing ⚠️
pkg/signature/keys.go	63.63%	8 Missing ⚠️
cmd/cosign/cli/sign/sign.go	40.00%	6 Missing ⚠️
cmd/cosign/cli/verify/verify.go	0.00%	4 Missing ⚠️
cmd/cosign/cli/verify/verify_attestation.go	0.00%	4 Missing ⚠️
test/cert_utils.go	40.00%	2 Missing and 1 partial ⚠️
cmd/cosign/cli/attest/attest.go	0.00%	1 Missing ⚠️
cmd/cosign/cli/verify/verify_blob_attestation.go	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4050      +/-   ##
==========================================
- Coverage   40.10%   36.94%   -3.16%     
==========================================
  Files         155      210      +55     
  Lines       10044    13411    +3367     
==========================================
+ Hits         4028     4955     +927     
- Misses       5530     7837    +2307     
- Partials      486      619     +133     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ret2libc]

I'm going to add a few tests to this.

[haydentherapper]

What do you think about limiting this to code under the --new-bundle-format flag, where VerifyBundle is called? Then most changes only need to occur in sigstore-go, we won't have to be concerned about unexpectedly breakages for current users, and we know the code will carry on to cosign 3.x.

[ret2libc]

What do you think about limiting this to code under the --new-bundle-format flag, where VerifyBundle is called? Then most changes only need to occur in sigstore-go, we won't have to be concerned about unexpectedly breakages for current users, and we know the code will carry on to cosign 3.x.

Sounds good, but we still want to modify the "sign"/"sign-blob" flow, don't we? At least to test the signing process through cosign and then the verification process in the new bundle format, correct?

[haydentherapper]

The sign-blob flow, yes, where we also use the new-bundle-format flag. We don’t have to include sign at the moment since we don’t yet support the new bundle format.

[haydentherapper]

Reviewed this for the Fulcio PR. This LGTM and I realize my comment about sign-blob isn't immediately relevant as we need to make all these changes first.

cosign/pkg/cosign/tlog.go

Line 240 in 8dd9e9b

Algorithm: swag.String(models.HashedrekordV001SchemaDataHashAlgorithmSha256),

needs to be updated as well.

[haydentherapper]

If we do the Fulcio change to accept ecdsa-p384-sha-384 and ecdsa-p521-sha-512, I'd add an end-to-end test that verifies signing and verification with these keys. You can generate a key, import it into the Cosign key format, then sign with IssueCertificate:true.