Jeff King venit, vidit, dixit 07.09.2016 10:39:
> On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
>> Now, I can't reproduce C on Linux[*], so there is more involved. It
>> could be that my patch just exposes a problem in our start_command()
>> etc.: run-command.c contains a lot of ifdefing, so possibly quite
>> different code is run on different platforms.
> Maybe, though my blind guess is that it is simply that on Linux we can
> open /dev/tty directly, and console-IO on Windows is a bit more
> complicated.
> You might also check your GPG versions; between gpg1.x and gpg2, the
> passphrase input handling has been completely revamped.

That's a good point to note.

gpg1 asks for the passphrase (without use-agent), gpg2 always delegates
to gpg-agent (and starts it on demand).

On Linux, gpg-agent says you should

export GPG_TTY=$(tty)

to make gpg-agent find the tty, and claims it's not necessary on Win.

In fact, it's not necessary on Linux either unless you want to use

Alas, be it gpg1.4.21 or gpg2.1.13, whatever pinentry, I do get the
passphrase prompt, even with curses (if GPG_TTY is set, which was
necessary before any patches already).

I put up a request for more input from the reporters in the github
issue. I guess that's the best way to reach them.

>> It would be great if someone with a Windows environment could help our
>> efforts in resolving issue C, by checking what is actually behind[**]: I
>> can't believe that capturing stderr keeps gpg from reading stdin, but
>> who knows. Maybe Jeff of pipe_command() fame? I'll put him on cc.
> I know nothing about Windows, but I'd be surprised if gpg is reading
> from stdin, as opposed to /dev/tty. It's probably more to do with how
> gpg finds the "tty" on Windows (presumably it looks at stderr for that).
> Anyway, I wrote pipe_command() in such a way as to be prepared for
> exactly this kind of thing, so it would be trivial to extend it to an
> extra descriptor. The trouble is that run_command() doesn't understand
> anything except stdin/stdout/stderr. We can open an extra pipe() before
> calling run_command(), and make sure it is not marked CLOEXEC. I don't
> know if there are other portability concerns, though.

My suggestion to try "--status-fd=3" was meant to test whether the above
could help: If fd=3 helps, then our capturing stderr is not the problem.
(If fd=3 does not help then we still don't know...)


Reply via email to