[pkg-gnupg-maint] Bug#787781: Bug#787781: gnupg-agent: broken pipe error when a program using agent is invoked by stdbuf -oL

[nfb]

Hi, thanks.
Well, after some quick tests the results push me to explain the whole
script, which i didn't do at the beginning to just keep to focus on the
issue itself without additional bloat, because in any case the error
is on the gpg functionality which is used by pass only. So everything
i wrote (with some corrections i'll write now) is also reproducible
without knowing the full details of my scripts, but we never know they
may be useful...


> > i have a script that uses pass [0] password manager, which on his hand
> > uses gpg-agent to remember the master passphrase, as you can see.
> > Also i have to filter its output, so i pipe it into another script,
> > but since i want the output to be unbuffered to get a more real-time
> > feedback, i tried calling it this way:
> >
> > stdbuf -oL pass <pass_arguments>

The script actually calls mpop pop3 client, which i set to use its
passwordeval functionality to retrieve appropriate passwords for each
account from pass password manager.
mpop is invoked via stdbuf (to achieve line by line printing) piping
its output into another script. So it may be logically represented
something like:
mpop (=> pass (=> gpg + gpg-agent)) | anotherscript
while the actual command in the script is:

stdbuf -oL mpop <mpop_arguments> | anotherscript

The second part after the pipe should be not relevant at all, since
the issue also happens without any piping.

The reason i decided to describe the full structure is that in the
mpoprc config file, pass is called just with the account i want the
password for as argument, such as:

passwordeval "pass <my_mail_account>"

And this results in the broken pipe error as reported.
Anyways i'm not able to get a broken pipe directly calling on a
terminal:

stdbuf -oL pass <my_mail_account>

which whould be equivalent, unless i also use the -c switch (that
copies the output to clipboard instead of the stdout). So:

stdbuf -oL pass -c <pass_arguments>

gives broken pipe.
This was the command i was using to test yesterday from the command
line, but i tought the -c switch was not relevant so in the quoted
command in my first mail i didn't specify it.
I decided to describe everything because these last steps seemed weird
to me.

So to sum up, the broken pipe error is present when mpop calls pass
with just the mail account as argument, or on the command line
specifying the -c switch too (always invoking them via stdbuf).

Another weird thing i noticed is that if i call consecutively multiple
times the command line command (the one with -c) discussed above, the
error happens one time but not the following, then it shows again and
so on alternating almost deterministically, but sometimes it doesn't
alternate.

 
> Is that the only difference between your arm device and your x86 device?

Yes, this should be the only difference, i keep the two machines
synced on most scripts and using the same packages (they are both
debian testing too). The kernel is different anyways, it's 3.8.11 on
th arm side, if that matters.

 
> From the footer in your bug report, you're using pinentry-curses on the
> arm device.  is this true for x86 as well, or are you using a different
> pinentry there?
> 
> on each machine, what do these show?
> 
>   readlink -f /etc/alternatives/pinentry
>   grep pinentry ~/.gnupg/*.conf
> 

I use pinentry on both. The readlink command shows
"/usr/bin/pinentry-curses" while grep finds nothing, on both machines.