-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added azure kms support #89
Conversation
This doesn't work as it is as the GCP input is just the KMS key id, not the fully formed URI: the idea is that user input is something they can just copy-paste from GCP KMS UI. User does not need to form the URI, the The AzureSigner.import_() arguments can be whatever you want,but I don't know why you would want to make your users build the full URI? Why not let AzureSigner build the URI from some logical values that the user understands (like keyid and vaultname)? I think now that we have mutliple different keys, we want to modify the UI so it first asks which keytype we want to use
Feel free to choose how you want to enter the azure details but it sounds like something like this would make sense:
|
Do not merge before: |
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
330cd05
to
80bdd31
Compare
Tests are failing as the AzureSigner does not exist in securesystemslib. It works locally so when the pr against securesystemslib is merged I'll rerun the tests. |
type=click.IntRange(0, 4), | ||
default=0, | ||
show_default=False, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about defaulting to sigstore (and not hiding the default)?
I'm a bit conflicted:
- it's pretty clear the sigstore support is a little experimental still, but...
- mostly for demonstration purposes I'd like to have default values that (once the current dependency fiasco is solved) just work if you keep pressing enter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree. Default to sigstore makes sense as that would make it easy to get on board. I'll update. I think for a real situation, when you are actually configuring a trust root, you don't blindly press enter, you think carefully about your config so there is no need to rely on the default values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also one thing I would like to have feedback on. The local testing key, before it was based on a "known value", now it's a "hidden option" (4). You are ok with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hiding option 4 seems good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me, apart from the default online key change
Updated the default option when chosing online key type. Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
No description provided.