Change password input for gpg from STDIN to dedicated fd #586
Conversation
This file contains hidden or 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
Remove last remnant of 9e820f3 The latest release of gpg1 is 1.4.23 from 2018. It is safe to assume, that there is no modern distribution, which ships this specific gpg1 version. As the workaround itself only applies to 1.4.11, any version before or after seem to be safe. This removal doesn't remove support for gpg1 in general as it isn't end-of-life. All the options in use are available with gpg1 and only a broken --status-fd seemed to be of concern. Closes dyne#581
Formerly a combined password+key divided by a newline was piped into the gpg operation which sets --passphrase-fd 0 to get the password from STDIN. This gets stripped from the pipe and only the encrypted data remains. This has some consequences for entered passwords in general. Mainly \ and % related. \ can be used for control sequences like \n, \t and \f. If those are used in passwords various stuff can happen. \n not at the end: Only the password up to the backslash is used and valid. \n at the end: <ToDo> \t not at the end: <ToDo> \t at the end: <ToDo> \f \f <Description for % stuff> In that regard change how gpg gets the password. Two ways for improvements: 1) use a specific file descriptor --passphrase-fd 3 and redirect the password via "3<<<$password". 2) switch to --passphrase-file and use an anonymous pipe <(print -R -n - "$password") In general the use of --passphrase-file is discouraged, but that should only apply if a real file is used. With the pipe only the respective file descriptor should be seen and not its content. Which only gpg is allowed to have access. And if gpg is completed the pipe and its content is gone. This solutions uses the first way as it is similar to the current solution. What changes: \n not at the end: Assuan still outputs a formated password, but the complete password is used. \n at the end: <ToDo> \t not at the end: password is functional \t at the end: <ToDo> \f \f <Does it help with % ?>
Member
|
I'm in favor of this, yet we'll need to state the introduction of a breaking change for anyone who uses passwords with control characters which were previously misinterpreted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
As a draft because of the same reasons mentioned in #585
Background of this PR is the issue that tomb has issues with passwords that try to use characters in a combination so they create control sequences for the shell. For example newline
\n, form feed\fand tabulator\t.This is due how the password is provided for the gpg call. gpg is used with
--passphrase-fd 0which reads the password fromSTDINuntil it encounters anewline. Unfortunately this means the shell interprets those character sequences in the password itself. Especially fatal in case of \n as this will reduce the password to this point. Example: you want to set passwordtest\ntest. gpg, while readingSTDIN, will stop at\nand the resulting password will be onlytest.Not sure yet what happens with the rest, but it does seem to be discarded in general and not added to or used as
TOMBSECRET.Two ways to avoid interpreting control sequences:
--passphrase-fdto a dedicated descriptor above 2 (like--passphrase-fd 3and input password like3<<<"$password"--passphrase-fileand use an anonymous pipeIn general the first option is similar to the current solution, just changing it to a different FD, which allows to avoid interpreting control sequences. But is untested if the redirect isn't visible while tracing.
This solutions changes the fd for the password input from STDIN to a new one file-descriptor (3 in this example).