You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When coming up with my solution for AWS KMS signing in #525 I found the add-signature tool quite painful to use as it requires a file with a specific format. Instead it would be useful to be able to either pipe in that file as outlined in #529 or to instead specify the key manually.
I propose the following
# normal usetuf add-signature targets.json \--signature <the-signature-string>--format "base64" # to support tools like AWS that return base64 rather than hex. normally this is "hex"--key-id <key-id>
# reading from stdinecho <the-signature-string> | tuf add-signature targets.json \--format "base64"--key-id <key-id>
the inclusion of the format will help to support users making use of tools like AWS KMS to do their signing and will give us a bit more flexibility going forward
One thing to think about would be how to support backwards compatibility with the current setup that expects a full json file as input. For this I suggest we have --format default to "json" which will then cause --key-id to be redundant and will expect the signature to be a full valid json string as it is now. That way the existing approaches will continue to work as expected.
The text was updated successfully, but these errors were encountered:
ChevronTango
changed the title
add-signature to be more generic
add-signature to support more formats
Aug 1, 2023
When coming up with my solution for AWS KMS signing in #525 I found the add-signature tool quite painful to use as it requires a file with a specific format. Instead it would be useful to be able to either pipe in that file as outlined in #529 or to instead specify the key manually.
I propose the following
the inclusion of the format will help to support users making use of tools like AWS KMS to do their signing and will give us a bit more flexibility going forward
One thing to think about would be how to support backwards compatibility with the current setup that expects a full json file as input. For this I suggest we have
--format
default to "json" which will then cause--key-id
to be redundant and will expect the signature to be a full valid json string as it is now. That way the existing approaches will continue to work as expected.The text was updated successfully, but these errors were encountered: