Decryption stalling after SIGINT

[Ángel]

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