feat: add: --password-file option for step crypto jwe decrypt #1060
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `encryptedKey` generated by `--type=jwk` in `step ca provisioner add` is in PBES2 format. This is hard-coded and difficult to change. Therefore, in the implementation before this commit, after the key to decrypt is entered in the standard input, the executor must interactively enter the password specified when generated in the standard input. The `--key` option and others cannot be used at this time because of formatting problems. However, trying to do this programmatically is difficult, as the format of `ui.PromptPassword` is too specific for manual execution, or reading stderr output, etc., and trying to add additional standard input passwords in a programmatic and automatic way is very It was very difficult. Therefore, I added the `--password-file` command line argument to provide an alternative that does not require an interactive operation. Since there was no problem reading the password file when generating it, I decided that there was no harm in reading the password file when decrypting it, and it was a natural implementation.
|
|
github-actions
bot
added
the
needs triage
|
I just realized that maybe it is not necessary because it can be specified with |
maraino
approved these changes
Nov 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Name of feature:
add:
--password-fileoption forstep crypto jwe decrypt.Pain or issue this feature alleviates:
The
encryptedKeygenerated by--type=jwkinstep ca provisioner addis in PBES2 format. This is hard-coded and difficult to change.Therefore, in the implementation before this commit, after the key to decrypt is entered in the standard input, the executor must interactively enter the password specified when generated in the standard input. The
--keyoption and others cannot be used at this time because of formatting problems. However, trying to do this programmatically is difficult, as the format ofui.PromptPasswordis too specific for manual execution, or reading stderr output, etc., and trying to add additional standard input passwords in a programmatic and automatic way is very It was very difficult. Therefore, I added the--password-filecommand line argument to provide an alternative that does not require an interactive operation. Since there was no problem reading the password file when generating it, I decided that there was no harm in reading the password file when decrypting it, and it was a natural implementation.Why is this important to the project (if not answered above):
For example, once this is merged, anyone can easily and automatically run the
gh_token.shscript for GitHub Enterprise that is on the official site.Configuring
step-caTemplatesIs there documentation on how to use this feature? If so, where?
The documentation is not specifically written because it is quite simple and a function that is already in other commands.
For now,
You can check it with
step crypto jwe decrypt --help.In what environments or workflows is this feature supported?
It would be useful to automatically decrypt JWK's encryptedKey.
The reason why
--keyis not allowed is that, as I said before, it is rejected due to formatting problems.I needed this feature for my own use in the first place.
As I said before, it was difficult to operate via standard input.
I didn't want to put too much load on the maintainer, so I refrained from doing so, but it was too difficult and I thought it would be a comfortable flag to add, so I added it.
In what environments or workflows is this feature explicitly NOT supported (if any)?
Supporting links/other PRs/issues: