pinentry-curses, pinentry-tty both freak out at control+c
Closed, DuplicatePublic


If I invoke gpg to unlock a private key, pinentry-curses pops up. If I hit ^C, gpg appears to exit, and my shell prompt comes up. However, some characters don't echo and some are replaced with asterisks. I can't even type reset into my terminal since some of the letters disappear. the only way to salvage the terminal is to open a new one, and kill pinentry-curses from there, and even then, the terminal is left in a weird state that makes it hard to reset, and I'm usually better off closing that terminal as well. If I don't go through this whole dance, any future gpg invocations just hang indefinitely when they get to the prompt for a passphrase.

Because of this behavior, I switched to pinentry-tty, and noticed slightly less annoying but similar behavior: control+C will send me back to the shell, but it still lurks in the background, grabbing keystrokes and making a mess. at least this one seems to give up after a few presses of the enter key.

Anyways, I suppose the solution would be to handle SIGINTs by invoking the pinentry program's normal exit routine (like the cancel button on the curses UI).


gpg 2.1.21, gpg-agent 2.1.21, pinentry-curses 1.0.0, pinentry-tty 1.0.0
dn3s created this task.May 30 2017, 9:24 PM
aa added a subscriber: aa.Jun 2 2017, 9:21 PM
werner assigned this task to marcus.Jun 7 2017, 1:20 PM
werner added a project: pinentry.
werner triaged this task as Normal priority.
werner added a subscriber: werner.

Marcus: That would be a good opportunity to get back to your old curses works ;-)
IIRC, we fixed similar bugs in the past but this is for the latest pinentry.

marcus moved this task from KW 24 to KW 25 on the g10code Sprint board.Jun 19 2017, 10:01 AM
marcus edited projects, added g10code Sprint (KW 25); removed g10code Sprint (KW 24).

The problem seems to be that the CTRL-C is sent to gpg, terminating it, but pinentry keeps running and interfers with the terminal. With "ps -j" we can verify that pinentry runs in the process group and session of gpg-agent, while gpg runs in its own process group within the shell session. So, the signal rightly goes to gpg.

The bug thus seems to be that gpg terminates without tearing down the gpg-agent/pinentry connection correctly first.

By the way, when terminating pinentry with "kill -TERM ...", it shuts down correctly, while CTRL-C show "gpg: signal Interrupt caught ... exiting" and a corrupt screen layout that is reset when pressing RETURN, further confirming the above diagnosis.

marcus moved this task from KW 25 to KW 26 on the g10code Sprint board.Jun 27 2017, 9:58 AM
marcus edited projects, added g10code Sprint (KW 26); removed g10code Sprint (KW 25).