Even in that case:

foo | gpg 2>gpg.log | bar

if the main gpg process opens "/dev/tty", then it will still get the user's
terminal. /dev/tty is strong magic -- it will work even if fds 0, 1, and 2 are
pointing elsewhere.

And if it then passes that file descriptor to an agent (I assume you're aware of
the ability to pass open file descriptors across unix-domain sockets, so that the
target process actually receives a copy of the same file descriptor) then the agent
will have the user's terminal also.

I reiterate my offer to help implement something like this, if you can point me to
the right place in the code (i.e. where *exactly* are these requests to the agent
that require user interaction happening? Where would be the best place to put file-
descriptor passing code?)

OK, here's what I hear you saying: Even if my patch would do the right thing in the common case
for 2.0.19, when 2.1 comes along it will stop helping.

I agree with you that *if you are using a long-lived agent*, then the patch I had proposed is not
sufficient. I had been discounting that case as "not the common case"; now I realize it is going
to be the common case soon.

I think, at this point, we're going to have to consider using file descriptor passing (SCM_RIGHTS)
from the gpg to the agent.

It *will* be the case that, even if someone has redirected stdin/stdout in the gpg process, that
the gpg process will be able to open its "/dev/tty" and get a useful file descriptor. I agree with
you that it can't (at least not portably) work backwards from that to find the *name* of its tty,
but it can at least open /dev/tty, itself.

If gpg then passes that open file descriptor across the unix-domain socket to the agent (at least
I assume unix-domain sockets are used for gpg/agent communication), then the agent will have a
copy of *that* file descriptor.

Can you point me to where the agent receives the set of data that makes up one "request" or "work
unit"? I can try to make a new patch that uses file-descriptor passing.

To reiterate: making the user *in the common case* set an environment variable is not acceptable.
Environment variables are a nice thing to be able to set to change behavior from the default; but
if the user is happy with the default behavior they should not have to set any environment
variables in order to use a piece of software. If I had to have one environment variable setting
for every program I used regularly, my .cshrc would be *huge*!

Thanks!

To restate: If you are starting the agent on demand, AND if you are feeding gpg
data on standard input, then initscr() will NOT do the right thing. At least on
FreeBSD. Are you saying that on your OS, initscr() will, internally to itself,
open "/dev/tty"?

If that's the case for you, then it's not the case for me on FreeBSD. The
initscr() on FreeBSD doesn't do any magic, it just uses fds 0 and 1. Hence the
fact that I am trying to get it to open /dev/tty in that case.

Yes, I saw the if (tty_name) in pinentry when I was looking through all of that
stuff. The problem for me is NOT that pinentry has no controlling terminal,
because I *am* starting the agent, as you say, on demand.

The problem for me is that pinentry has inherited file descriptor 0 from gpg,
and it is *not* a tty, it is the input file that I am asking gpg to process.

So no, the if (tty_name) thing doesn't really work too well if you are feeding
gpg something on its standard input, AND if you are starting gpg-agent on
demand.

Ugh. That trick doesn't work on Solaris, it looks like.

The basic place I'm trying to get to is... in the simple case... a user logs in,
and isn't using gpg-agent, gpgme, or anything like that... and just types:

some_command | gpg -a --clearsign > some_file

that it will work.

It seems *to me at least*, like defaulting to the literal filename "/dev/tty",
as in my patch, at least *does no harm*.

Maybe it doesn't solve the gpg-agent case or the gpgme case 100%. But at least
it makes the simple case work. And people can always override it by setting
GPG_TTY, if they need to.

Make sense?

If I come up with a modified patch that opens /dev/tty, calls ttyname on *that*,
and gives *that* tty name to pinentry, will you consider it?

Thanks!!

(btw, I don't use the agent at all... my usage of gpg is very vanilla, just the
plain way of using it on the command line that has worked ever since gpg1, but
is now broken in gpg2)

Looks like calling ttyname() on a freshly open()ed "/dev/tty" works, at least on
FreeBSD:

cat ttyname.c

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv)
{
int fd = open("/dev/tty", O_RDWR, 0);
char *s = ttyname(fd);
printf("%s\n", s ? s : "NULL");
return 0;
}

gcc -o ttyname ttyname.c
./ttyname

/dev/pts/9

./ttyname < /dev/null >& /tmp/foo
cat /tmp/foo

/dev/pts/9

Notice that even though the program's stdin was /dev/null, and the program's
stdout and stderr were both going to a file (I use tcsh, hence the >& syntax),
and yet it still managed to figure out what the terminal was.

Another thought would be that ttyname(2) is possibly somewhat more likely to
give a useful result than either ttyname(0) or ttyname(1). That is, assuming
that people redirect stdin and stdout all the time, but rarely redirect stderr.

I'm just tossing out ideas here. My gut reaction is still "just use /dev/tty",
but I'm hoping that if I toss out some ideas that maybe one of them will be
helpful. :-)

Hmmmm.

Would it work to open /dev/tty, and then call ttyname on *that*? Rather than
calling ttyname on stdin always?

I really dislike the solution of "the user must set $GPG_TTY". That is broken,
period. If I'm not making use of any advanced functionality like the agent,
please don't penalize me (as a user) for the fact that such advanced
functionality *exists*.

I want the simple case -- i.e. I'm logged in, and I run gpg on a single tty --
to Just Work, without me having to set any environment variables to make it
work.

Ack! Updated patch. Silly mistake in the first one.

D156: 356_gnupg-dev-tty.patch

D157: 355_gnupg-dev-tty.patch