Add flag for manually specifying a hash algo when verifying #1071
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
While, at the time of writing, it's not possible to manually specify the signature digest algorithm which should be used when signing an image, some KMS providers have key types which force a digest algorithm which isn't sha256; e.g. GCP KMS with RSA4096 / SHA512 keys.
Cosign will happily use these keys for signing and will infer the digest algorithm based on what the KMS provider mandates, leading to a situation where cosign generates signatures which it can't later verify.
This commit adds a new
--signature-digest-algorithm
flag which allows the user to manually specify one of 4 commonly-used secure hashes when usingcosign verify
.Notes
--signature-digest-algorithm
tocosign sign
, which I think would be desirable but is a much bigger piece of work and maybe needs more discussion.--signature-digest-algorithm
as a flag name - it's a bit wordy. Happy to rename if someone has a better suggestion!Testing
I've tested that this works correctly using a test image which I think should be publicly available. Using this commit, I can successfully run:
Ticket Link
Related to #946, specifically this comment. That issue is more broad, though, and there's probably more work to be done in the future for that issue to be completed.
Release Note