Mailing List Archive

Decryption stalling after SIGINT
Hello,

I am seeing some strange behavior with gpg --decrypt <path>. I had to
lookup a password recently, and so naturally pressed Control+C to cancel
the prompt. However, when gpg terminated, it did not fully cleanup the
terminal. Further commands in my shell were obfuscated with asterisks (*).

That's okay. I can open a new terminal session, in my case a fresh
Terminal.app tab. With the key password in hand, I ran gpg --decrypt <path>
again. This time, I didn't get a password prompt at all. gpg froze here,
with no visible output. Cancelled with Control+C again. Tried a third time.
Same behavior: Blocking silent, infinite patience.

No idea what is going on with the gpg command line interface. I found that
rebooting temporarily alleviated the problem, and I was able to finally
decrypt the file.

This happened with GnuPG v2.2.20, on zsh 5.3, from Homebrew, on macOS 10.14
Mojave. I never configured the unbound service. Would that have anything to
do with this behavior?

--
Cheers,
Andrew
Re: Decryption stalling after SIGINT [ In reply to ]
On 2020-07-07 at 18:05 -0500, Andrew Pennebaker via Gnupg-users wrote:
> Hello,
>
>
> I am seeing some strange behavior with gpg --decrypt <path>. I had to
> lookup a password recently, and so naturally pressed Control+C to
> cancel the prompt. However, when gpg terminated, it did not fully
> cleanup the terminal. Further commands in my shell were obfuscated
> with asterisks (*).
>
>
> That's okay.. I can open a new terminal session, in my case a fresh
> Terminal.app tab. With the key password in hand, I ran gpg --decrypt
> <path> again. This time, I didn't get a password prompt at all. gpg
> froze here, with no visible output. Cancelled with Control+C again.
> Tried a third time. Same behavior: Blocking silent, infinite patience.
>
>
> No idea what is going on with the gpg command line interface. I found
> that rebooting temporarily alleviated the problem, and I was able to
> finally decrypt the file.
>
>
> This happened with GnuPG v2.2.20, on zsh 5.3, from Homebrew, on macOS
> 10.14 Mojave. I never configured the unbound service. Would that have
> anything to do with this behavior?

My guess is that when you opened gpg on the second terminal, there was
still a pinentry active on the first one, and so gpg asked gpg-agent for
decryption, which was awaiting for input on the first terminal, and was
thus "frozen".
I don't see how your Ctrl-C would have ended in such situation, though.
It would have been interesting to see a process list of what was going
on.

Best regards





_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Decryption stalling after SIGINT [ In reply to ]
On Tue, 7 Jul 2020 18:05, Andrew Pennebaker said:
> I am seeing some strange behavior with gpg --decrypt <path>. I had to
> lookup a password recently, and so naturally pressed Control+C to cancel
> the prompt. However, when gpg terminated, it did not fully cleanup the

This will terminate gpg and thus the connection to gpg-agent. However,
depending on the type of the pinentry it may happen that the pinentry is
still active and you did not notice that. It will eventually time out
and a new pinentry can come up; a complete deadlock should not happen,
even not on macOS.

Please run the gpg commands with option --verbose so you should be
notified about active pinentries; for example:

gpg: pinentry launched (5591 gtk2 1.1.1-beta29 /dev/pts/123 xterm [...]

If this does not reveal anything add

--debug ipc

to the gpg invocation and you will see the communication between gpg and
gpg-agent and possible with dirmngr (for network actions).


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.