Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add kms decrypt argument for base64 encoded input #2063
The output for
It would be useful if there was an additional
5 similar comments
+1, in the meantime for anyone else looking:
6 similar comments
We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.
This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.
As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.
We’ve imported existing feature requests from GitHub - Search for this issue there!
And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.
GitHub will remain the channel for reporting bugs.
Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface
-The AWS SDKs & Tools Team
This entry can specifically be found on UserVoice at: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168328-add-kms-decrypt-argument-for-base64-encoded-input
I'd love to see this feature. Just to reiterate why it's needed....
When you encrypt some data with the kms encrypt command the output is base64 encoded. Base64 encoded encrypted values are widely used. For example storing encrypted environment vars (this is how lamba encryption helpers work).
When you call the kms decrypt command the only option is to pass the encrypted data as binary (blob). So all the base64 values have to first be decoded to binary and then decrypted.
You can't pass the encrypted binary data via stdin to the command - so something like this doesn't work either...
The morale of the story is... PLEASE add --ciphertext-base64 as an option. And while you're at it, it would be good to be able to support stdin too.
Well I'll eat my words... it turns out you can use standard in (on *nix anyway)
I hope that helps some of you too!
Yes, but the base64 executable still needs to read from a file, which is an hassle and potential security risk to leave lying around.
Just like when encrypting, we need to be able to simply pass the base64 string on the command line which can only be done if that AWS CLI accepts base64 encoded text.
1 liner with no file (ugly but works)
This is MacOS BTW ... you might need to use
I am really supportive of this request. If fileb:///dev/stdin is supported, then that should appear in the documentation. But, it is complicated. I think having --ciphertext-blob-file or --ciphertext-blob-64 would add a lot of clarity. I have a case where the base64 ciphertext is stored in DynamoDB. I need to retrieve that, base64 decode it and save it to a file (or send over a pipe) and then AWS CLI has to turn around and do the base64 encoding. Keeping ciphertexts and plaintexts off the file system is an important security feature.
referenced this issue
Dec 28, 2018
reiterating something from #1043 - this doesn't need to be a separate argument, as
By my understanding, ciphertext-blob does not accept an argument without a protocol currently (as only fileb is supported), so this would not be a breaking change