pull: Add support for sign-verify=<list> #2105
Conversation
cgwalters
force-pushed
the
pull-signapi-explicit
branch
from
3e87f15
to
95fe404
Compare
The goal here is to move the code towards a model where the *client* can explicitly specify which signature types are acceptable. We retain support for `sign-verify=true` for backwards compatibility. But in that configuration, a missing public key is just "no signatures found". With `sign-verify=ed25519` and no key configured, we can explicitly say `No keys found for required signapi type ed25519` which is much, much clearer. Implementation side, rather than maintaining `gboolean sign_verify` *and* `GPtrArray sign_verifiers`, just have the array. If it's `NULL` that means not to verify. Note that currently, an explicit list is an OR of signatures, not AND. In practice...I think most people are going to be using a single entry anyways.
cgwalters
force-pushed
the
pull-signapi-explicit
branch
from
95fe404
to
5cb9d0d
Compare
There was a problem hiding this comment.
@cgwalters I really like the way you did in this MR. Thanks!
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, d4s The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test sanity |
|
/override continuous-integration/jenkins/pr-merge |
|
@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
In ostreedev@588f42e we added a way to add keys for sign types when doing a `remote add`, and in ostreedev#2105 we extended `sign-verify` to support *limiting* to an explicit set. This PR changes the *default* for `remote add` to combine the two - when providing an explicit `--sign-verify=type`, we now limit the accepted types to only those.
The goal here is to move the code towards a model
where the client can explicitly specify which signature types
are acceptable.
We retain support for
sign-verify=truefor backwards compatibility.But in that configuration, a missing public key is just "no signatures found".
With
sign-verify=ed25519and no key configured, we canexplicitly say
No keys found for required signapi type ed25519which is much, much clearer.
Implementation side, rather than maintaining
gboolean sign_verifyandGPtrArray sign_verifiers, just have the array. If it'sNULLthat meansnot to verify.
Note that currently, an explicit list is an OR of signatures, not AND.
In practice...I think most people are going to be using a single entry
anyways.