Tomb icon indicating copy to clipboard operation
Tomb copied to clipboard

Change password input for gpg from STDIN to dedicated fd

Open Narrat opened this issue 5 months ago • 0 comments

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 \f and tabulator \t. This is due how the password is provided for the gpg call. gpg is used with --passphrase-fd 0 which 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 \n as this will reduce the password to this point. Example: you want to set password test\ntest. gpg, while reading STDIN, will stop at \n and the resulting password will be only test. 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:

  • change --passphrase-fd to a dedicated descriptor above 2 (like --passphrase-fd 3 and input password like 3<<<"$password"
  • use --passphrase-file and use an anonymous pipe

In 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).

Narrat avatar Oct 03 '25 16:10 Narrat