Hot answers tagged


Perhaps you could just rm -rf ~/.gnupg. It works for my situation. I just force stopped the first time I ran gpg --gen-key, which might lead me to this agent_genkey failed: Timeout error.


The difference between gpg1 and gpg2 that I was noticing arises from the fact that gpg2 uses an external cryptographic library, libgcrypt, whereas gpg1 uses an integrated cryptographic library. And specifically, Homebrew updated to version 1.7.4 of libgcrypt on December 10, which introduced a regression in the libgcrypt code, leading to the insecure memory ...


I'm seeing exactly the same problem and, according to a MacPorts bug report, it's coming from libgpg-error and not seen with GnuPG version 2.1.16. So it seems we need to either wait for the gnupg21 port to move from 2.1.15 to 2.1.16 or locally modify and rebuild the gnupg21 port (and maybe some of its dependencies?) to upgrade ahead of the official update. ...


Most probably you have gpg-agent installed in a 32-bit version. macOS 10.15 only supports 64-bit programs, so it tells you the CPU type in the executable is not supported. The fix is to reinstall gpg-agent in the 64-bit version. You can check the type of executable by running the following in the Terminal: file /usr/local/bin/gpg-agent Most probably it will ...


In my case running killall gpg-agent allowed the next key generation attempt to succeed. This is preferable to deleting ~/.gnupg and/or ~/.gpg-agent-info if you can avoid doing so (as referenced in another answer). (On macOS 11.2.3 Big Sur)


Try to uncheck Store passphrases in OS X Keychain by default and press Delete stored passphrases button in GPGPreferences if you installed GPG Suite. Also try to comment this line from your ~/.gnupg/gpg.conf: use-agent


If you selected Save in Keychain when entering your password to GPG, it was saved in your login keychain. This keychain is automatically unlocked when you enter your password to log in or unlock from sleep, and you can manually lock it from Keychain Access (or its menu bar item) and/or remove the item from keychain to enter it every time.


By default, macOS does not use anything under /usr/local, so yes you can brew link --overwrite gnupg safely.


I'm experimenting with veertu to run a 10.11 VM inside 10.12 native for cases like this. It's clearly not ideal, but depending on how large your mailboxes are - it might let you keep working with encrypted emails while that specific tool gets reworked (assuming it does get ported).

Only top voted, non community-wiki answers of a minimum length are eligible