When a user type Control-C to interrupt gpg operation (when pinentry-curses
dialog is active), gpg should shutdown pinentry gracefully.
Configure gpg-agent with pinentry-curses, minimum test case is:
$ gpg --sign some.txt [Type Control-C, when you see curses dialog]
The pinentry process won't be killed by Control-C (because it doesn't have
controlling terminal).
Expected behavior is when gpg cancels its operation, it should notify
gpg-agent so that gpg-agent can cancel pinentry.
Actually there should be no need for gpg to notigy gpg-agent and thus pinentry
about a Ctrl-C. Due to Ctrl-C the gpg process dies and thus the connection to
gpg-agent receives an EOF/SIGPIPE and gpg-agent will shuot it down. Thus the
connection cleanup handler of gpg-agent needs to kill an open pinentry - I
tought this is already done.
Or is it the case that gpg does not see the Ctrl-C?
Just checked:
/* Reset the pinentry (in case of popup messages). */ agent_reset_query (ctrl);
Thus the pinentry is only closed if it is used as a simple popup winode (e.g.
"Insert card with serial number xxx") but not for a regular Pinentry.
werner: What is your call to action? Should pinentry always be shutdown or is
the status quo acceptable? Thanks.
This appears to be https://bugs.debian.org/850946 and it does not appear to be fixed to me.
To replicate:
export GNUPHOME=$(mktemp -d) echo pinentry-program /usr/bin/pinentry-curses > $GNUPGHOME/gpg-agent.conf gpg --pinentry-mode=loopback --passphrase abc123 --batch --quick-gen-key 'test key' echo test > $GNUPGHOME/test.txt gpg --sign $GNUPGHOME/test.txt
then hit Ctrl-C,
It was fixed in GnuPG master by rGc395f8315362: agent: Terminate pinentry process gracefully, by watching socket. and rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM..
Those will be in GnuPG 2.3.