Page MenuHome GnuPG

gpg-agent manual page says to always add GPG_TTY to `.bashrc`
Open, HighPublic


gpg-agent(1) says:

You should always add the following lines to your .bashrc  or  whatever
initialization file is used for all shell invocations:

  export GPG_TTY

It is important that this environment variable always reflects the out‐
put of the tty command.

As i wrote over on,

Always setting this in .bashrc implies that the current tty is published in the environment.

what happens with this configuration if (for example) the user:

  • launches a terminal emulator (system allocates /dev/pts/14)
  • in that terminal, runs thunderbird &

at some point in the future, thunderbird is going to talk to enigmail, which is going to invoke gpg, which might or might not talk to a running gpg-agent.

Ideally, thunderbird doesn't try to tell the agent to talk to the terminal to prompt the user for their passphrase.

even worse, if the user:

  • exits that terminal

and then later another pty is allocated on that machine which happens to grab /dev/pts/14 (e.g. imagine some other user ssh's in from the outside in an interactive session), then we definitely don't want gpg-agent to try to talk to that user's pty. (normally, they wouldn't have the permissions to do so, but that user could chmod o+rw /dev/pts/14 to scoop up the communications and use it to test passwords against the agent). This isn't a terrible breakage, but it doesn't seem like a great idea either.

furthermore, having pinentry prompt the user on the TTY is known to not work well if the tty is in use by another process. See the upstream discussion.

Event Timeline

werner triaged this task as High priority.Sep 19 2017, 8:01 AM
werner added a subscriber: werner.

IIRC, the actual reason for introducing GPG_TTY was a problem with GTK which required a tty for whatever reasons. The original user for the curses pinentry was Mutt and that didn't require that envvar. A much, much better solution would be a fixed ctermid(3) to return the real controlling tty and not the virtual tty /dev/tty. Unfortunately other libc implementations behave the same (I just checked OpenBSD).