Control: affects 847389 + gpg-agent On Wed 2016-12-07 19:59:07 +0200, Teemu Likonen wrote: > File /etc/skel/.bashrc should contain line "export GPG_TTY=$(tty)". > GnuPG agent's (package: gpg-agent) man/info page says that > > You should always add the following lines to your .bashrc or > whatever initialization file is used for all shell invocations: > > GPG_TTY=$(tty) > export GPG_TTY > > gpg-agent is or will be on every Debian system because package gnupg > (2.1.x) depends on it. I think it would be a good idea to have those > required commands on /etc/skel/.bashrc.
I'm not convinced this is a good idea, though i confess i've always been a bit confused about bash's initialization process, with the distinctions between interactive shells, login shells, etc. Always setting this in .bashrc implies that the current tty is published in the environment. what happens with this configuration eif (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 over here: https://dev.gnupg.org/T3217 If there were no downsides or risks to it, i could see adding extra code to the default bash initialization script to handle some odd corner cases. But given that there are some situations where it isn't desirable, i don't think this is a great thing to put into the defaults. Users who need this setting are generally special cases, and can figure out how to put it in themselves if they need it (and they might not need it at all anyway). Users who just have and work with a graphical environment should probably stick with the defaults rather than have one additional setting exposed that has weird breakages. I've written my thoughts and my current understanding above. If my reasoning or my facts are flawed, i'm open to being convinced otherwise. but currently i don't think it's a worthwhile change. --dkg
signature.asc
Description: PGP signature
