cliplugin: add VerifySignature#1944
Conversation
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
|
@haydentherapper @loosebazooka |
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
| } | ||
|
|
||
| // VerifyOptions contains the values for signature.VerifyOption. | ||
| type VerifyOptions struct { |
There was a problem hiding this comment.
What is the motivation for defining another structure? Can we just have an Options structure with common options?
There was a problem hiding this comment.
We could, but then the JSON schema would also change, making things a bit more complicated for plugin authors of other languages that would need to parse the json objects directly.
In case that we add or remove any options, some options might no longer be common, but belong in other opts structs. keeping the opts separate minimizes that breakage, and I think keeps things simpler for sigstore maintainers.
There was a problem hiding this comment.
OK, I see you're mirroring the existing APIs as well.
| } | ||
|
|
||
| // VerifyOptions contains the values for signature.VerifyOption. | ||
| type VerifyOptions struct { |
There was a problem hiding this comment.
OK, I see you're mirroring the existing APIs as well.
| // VerifyOptions contains the values for signature.VerifyOption. | ||
| type VerifyOptions struct { | ||
| RPCOptions RPCOptions `json:"rpcOptions"` | ||
| MessageOptions MessageOptions `json:"messageOptions"` |
There was a problem hiding this comment.
To confirm, if I want to verify an object without passing its digest, this is passed over stdin?
There was a problem hiding this comment.
Yes. The message is the object to be verified, and it's sent to invokePlugin() as stdin.
| DefaultAlgorithm: &DefaultAlgorithmResp{DefaultAlgorithm: "any-algo"}, | ||
| CreateKey: &CreateKeyResp{PublicKeyPEM: []byte("mypem")}, | ||
| SignMessage: &SignMessageResp{Signature: []byte("any-signature")}, | ||
| DefaultAlgorithm: &DefaultAlgorithmResp{DefaultAlgorithm: testAlgorithm}, |
There was a problem hiding this comment.
I feel like this test should test closer to what's expected rather than one big chunk? Can we split it in to parameterized testcases within this test?
| opt.ApplyCryptoSignerOpts(&signerOpts) | ||
| } | ||
|
|
||
| if len(digest) == 0 { |
There was a problem hiding this comment.
it's a bit confusing that the user can provide message or digest here. I would think it's one or the other?
There was a problem hiding this comment.
more specifically, I don't think the user should be able to specify both (because it could be error prone?)
There was a problem hiding this comment.
I think I agree, but since the interface allows both, we have to respect that for now.
There was a problem hiding this comment.
alright, can we leave an issue open about this? I feel like if we're gonna muck with the API, now would be the time.
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Signed-off-by: Ramon Petgrave <ramon.petgrave64@gmail.com>
Summary
Adds the VerifySignature method.
Release Note
Adds the VerifySignature method.
Documentation
No new documentation.