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
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