Change password input for gpg operations #585
Draft
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 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 second way as it isn't completly sure if the content of the redirect will be visible or not. 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 % ?>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Creating as draft, as this needs to be thoroughly tested and checked and isn't finished/cleaned up yet.
If finished the commit messages will be updated to include the issues it closes (if any...).
Background of this PR is the issue that
tombhas 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
gpgcall.gpgis used with--passphrase-fd 0which reads the password from STDIN until it encounters a newline. Unfortunately this means the shell interprets those character sequences in the password itself. Especially fatal in case of\nas 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 pipe (how it is done with this PR)In general the first option is similar to the current solution. But is untested if the redirect isn't visible while tracing. But I will also create a draft with that solution. Makes it easier to compare and check by others.
The second option uses an option which is discouraged. But the anonymous pipe should address concerns in regard to that.