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