[PATCH] Check for GPG_TTY as well as DISPLAY.
bjk at luxsci.net
Thu Oct 22 00:07:20 CEST 2015
On Wed, Oct 21, 2015 at 09:25:17PM +0200, Werner Koch wrote:
> On Wed, 21 Oct 2015 01:59, bjk at luxsci.net said:
> > There doesn't seem to be a way to set the tty for a pinentry to prompt
> > on in gpgme if isatty() fails (daemon process). This patch uses the
> > GPG_TTY environment variable as the value of --ttyname when set, and the
> > value of ttyname_r() if not.
> This will change the behaviour of most gpgme using applications. We
> need to better understand the problem and evaluate the risks of breaking
I have a server that runs detached from a terminal and uses gpgme which
spawns gpg2 and pinentry. Clients connect to this server which invoke
the actual commands on the server to spawn gpg2 and pinentry. Since
gpgme uses isatty() to determine what to pass as --ttyname to gpg2, if
isatty() fails (which it will for a background process) then there isn't
a way for pinentry to know what tty the client is on. The patch obtains
the tty from the GPG_TTY environment variable. The server sets GPG_TTY
via a command that the client has the value for.
I suppose it may be better to change the test around. So rather than
if (!_gpgme_getenv ("GPG_TTY", &tmp_ttyname) || isatty (1))
if (isatty(1) || !_gpgme_getenv ("GPG_TTY", &tmp_ttyname))
which would keep the original behavior but not work for my case as the
foreground server process would catch the pinentry rather than the
client on another tty.
Would that be OK to push after keeping the isatty() test order?
More information about the Gnupg-devel