Change password input for gpg from STDIN to dedicated fd - #586
Open
Narrat wants to merge 2 commits into
Open
Conversation
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. |
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
Narrat
force-pushed
the
optim/password-input-2_fd
branch
from
June 25, 2026 20:01
a8b0f53 to
9febdba
Compare
Collaborator
Author
|
Time flew by... Somewhere in the argon test cases. But running the tests locally went through without an issue. |
Narrat
marked this pull request as ready for review
June 25, 2026 20:12
This was
linked to
issues
Jun 25, 2026
GPG was used in way, that the password for the payload and the payload
was piped into GPG separated by a newline ("--passphrase-fd 0" where 0
is STDIN). It will then read the input until a newline is encountered
and strip it from the pipe. After which only the encrypted payload
remains.
This has some consequences for passwords in general, as the running
shell is involved and may interpret ANSI Escape Sequences.
ANSI Escape sequences can be used for various tasks and are
non-printable characters.
Build with a backslash ("\"), they create control sequences
like \n (newline), \t (horizontal tab) and \f (formfeed).
If those are used in passwords various stuff can happen.
\n for example will shorten the password depending on its position.
\ at the end of password will nullify the newline separator between the
password and the encrypted payload.
See KNOWN_BUGS.md for a table with some cases.
To solve those unintended changes the file descriptor is changed from 0
(STDIN) to 3. Which is the next free one after 1 (STDOUT) and 2 (STDERR).
The password will be redirected via "3<<<$password".
This solution won against a switch to --passphrase-file and the use of 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. For which only gpg is
allowed to have access. And if gpg is completed the pipe and its content
is gone.
What changes:
pinentry or more accuratly assuan will still output a (percent)formated
password, but the shell won't interfere anymore.
This does not address passwords that contain % and the difference
between entering the password via pinentry and --tomb-pwd.
Addresses dyne#304
Narrat
force-pushed
the
optim/password-input-2_fd
branch
from
June 25, 2026 20:22
9febdba to
974784f
Compare
Member
|
Thanks, this was on my mind for long now. So good to finally fix and properly document corner cases as you did. Give me some time to test myself and perhaps cover it with some specific tests. |
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
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).