Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#41193 - [pinentry] gpg-agent (at least pinentry-curses): enters endless loop (when used from within pipe)

Attached to Project: Arch Linux
Opened by Steffen Nurpmeso (sdaoden) - Monday, 14 July 2014, 11:24 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 05 December 2015, 04:23 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Gaetan Bisson (vesath)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


First: sorry for reporting this too late, i was too tired on saturday...

On saturday, before releasing the new S-nail v14.7.2 (in testing -- it adds *agent-shell-lookup* support for encrypted password storage, e.g. for use with gpg(1)) i've updated my ArchLinux system (pacman still says it is up-to-date) and afterwards this error occurred.

For testing i've used gpg-agent with pinentry-curses and when i use s-nail interactively everything is still fine and the passphrase-enter window pops up regulary; however, if i start it as part of a pipe, as shown below, the passphrase-enter window won't come up and instead pinentry-curses will consume all CPU time and loop endlessly unless explicitly killed via -QUIT.

Additional info:
* core/gpgme 1.5.0-1

Steps to reproduce:
You need the S-nail from testing (i'm too lazy to discover other ways).
$ echo PASS > /tmp/.pass
$ gpg -e /tmp/.pass
$ cat > /tmp/t.rc <<__EOT
set v15-compat
set smtp=nobody@localhost
set agent-shell-lookup='gpg -d /tmp/.pass.gpg'
$ echo bla|MAILRC=/tmp/trc s-nail -n -dvv -s sub du@auch
..^C to interrupt here..

This should hang and leave an endlessly looping pinentry-curses after interruption around (note that gpg correctly states it has been interrupted) which needs to be kill(1)ed with -QUIT explicitly.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 05 December 2015, 04:23 GMT
Reason for closing:  Upstream
Comment by Steffen Nurpmeso (sdaoden) - Saturday, 16 August 2014, 21:03 GMT
Huhu, just want to mention that the problem still exists with `gpg (GnuPG) 2.0.26'.

P.S.: and i start the agent via

$ eval `gpg-agent --daemon \
--pinentry-program=/usr/bin/pinentry-curses \
--max-cache-ttl 99999 --default-cache-ttl 99999`

P.P.S.: note that in the first message the ressource file is `t.rc', thus it should read

$ echo bla|MAILRC=/tmp/t.rc mailx -n -dvv -s sub du@auch
Comment by Steffen Nurpmeso (sdaoden) - Wednesday, 20 August 2014, 09:54 GMT
I've send a message to upstream on monday (yet sticking in some moderator queue though i think), so i think further stuff coming directly down from there. :)
Comment by Steffen Nurpmeso (sdaoden) - Saturday, 13 June 2015, 14:21 GMT
Hello, i got a mail yesterday, tried today and answered the following.
I request closure thereafter as i fail to see what an ArchLinux bug task can help with this one.


NIIBE Yutaka <gniibe (at) fsij (dot org)> wrote:
|Thank you for your report on 2014-08-25.

hm. :)

|On 08/25/2014 10:17 PM, Steffen Nurpmeso wrote:

|> [2] <>
|Since it's still opened in the bug tracker, I'm writing to you.

|Pinentry is under active development now. Please try newer version.

I must admit that S-nail (the MUA i maintain) is still not very
kind to programs it starts (it should restore terminal settings
before and after running external commands, it should properly
deal with TTOU etc.), and i can confirm that i cannot reproduce
the endless loop on a(n ArchLinux) system updated just 15 minutes

$ pla|grep -i gpg-agent
steffen 4033 1 0.1 1.1 2964 Ss ? 00:00:00 gpg-agent --daemon --pinentry-program=/usr/bin/pinentry-curses --max-cache-ttl 99999 --default-cache-ttl 99999
$ echo bla|MAILRC=/tmp/.rc mailx -n -dvv -s sub du@auch
LOAD 80 bytes <set v15-compat smtp=nobody@localhost agent-shell-lookup='gpg -d /tmp/.pass.gpg'>
user = steffen, homedir = /home/steffen
gpg: encrypted with 4096-bit RSA key, ID A1862748, created 2014-07-08
"Steffen Nurpmeso <>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key
*agent-shell-lookup* execution failure (`gpg -d /tmp/.pass.gpg')
"/home/steffen/dead.letter" 1/4
... message not sent.

But note that screen handling is still completely messy from the
pinentry side of the road, here just two snippets of what i see:

│ Please enter the passphrase to unlock the OpenPGP secret key: │
│ "Steffen Nurpmeso <>" │
│ 4096-bit RSA key, ID A1862748, │
│ created 2014-07-08 (main key ID 3D765288). │
│ │
│ │
│ Passphrase: __________________________________________________ │
│ gpg: signal Interrupt caught ... exiting │
│ <OK> <Cancel> │

│ │
│ Passphrase: __________________________________________________ │
│ │
│ <OK> <Cancel> │
└─────────────────────────────────────────────────gpg: signal Interrupt caught ... exiting

Btw.: does pinentry-gtk2/-qt4/.. also stop working when not
running on a terminal?
Ciao (and have a nice weekend)

Comment by Steffen Nurpmeso (sdaoden) - Tuesday, 16 June 2015, 11:20 GMT
NIIBE Yutaka of GNUPG actually moved the issue to the GNUPG bug tracker[1].

Comment by Gaetan Bisson (vesath) - Saturday, 05 December 2015, 04:22 GMT
Could you please check whether gnupg-2.1.10-1 and pinentry-0.9.6-2 from [testing] still have your issue? If they do, please report it upstream.