gpgme+gpgsm bug: fails when stdout redirected

Marcus Brinkmann Marcus.Brinkmann at
Wed Jan 28 21:13:33 CET 2004

On Wed, Jan 28, 2004 at 08:51:32PM +0100, Albrecht Dreß wrote:
> O.k., I see the problem... but this means that this process will *always*  
> fail when I simply redirect my output somewhere, which is obviously a bad  
> situation.

I didn't say that the current situation is any good :)  I was just laying
out exactly what happens right now.  What should happen is on a different
sheet of paper.

> IMHO, it should be possible to at least catch the missing tty  
> if the DISPLAY environment variable is set, in which case all downstream  
> agents had to use X11, in the worst case by running an xterm (should  
> always be present in X11 installations).

We definitely should catch the situation "no tty available", pass this
information down to the pinentry layer, and let it decide what to do.
The pinentry might not be able to use X, then it will fail.  Or it might be
able to use X, and do that without failing (if DISPLAY is available).

> The same applies if the tty is  
> present, but not X11, so everybody had to use ncurses (or whatever).

This already works.  What doesn't work is the reverse direction above.
It's not hard to fix, I think.  We just need to catch the situation and pass
it down.

> The  
> only situation when those processes are *really* lost if neither X11 nor  
> the control terminal is available - no idea how likely this is.

Right.  GPGME should still just pass this information down the layers. 
Pinentry will then fail (if it is ever invoked -- it might be that gpg-agent
has the passphrase cached).  The pattern here is that GPGME is just
responsible to provide all available information, and the lower layers
decide what to do.

This will have to be fixed.  It's now on the third place on my todo list.
Thanks for catching it!


`Rhubarb is no Egyptian god.' GNU    marcus at
Marcus Brinkmann              The Hurd
Marcus.Brinkmann at

More information about the Gnupg-devel mailing list