I use GPG, specifically GnuPG, on Arch Linux and Windows. Both OSes mount my home directory from my NAS, which contains amongst others my GPG settings and keys. Now, my Arch Linux GnuPG installation got updated from the “stable” 2.0.x series to the “modern” 2.1.x series, which seems to use a new keyring for storing keys. Now, the Windows Gpg4Win installation came with GnuPG 2.0.x, which could no longer find secret keys created under Arch Linux…
Update 17 October 2017: You can now simply install GPG4Win (3.0.0 or later) to get a recent version of GnuPG (2.2.1 for GPG4Win 3.0.0) on Windows. To use the same keys, I created an environment variable called GNUPGHOME on Windows (pointing to my Linux .gnupg directory), made sure my pinentry program configuration from Linux was not used (it’s in the gpg-agent.conf file), and at some point in the past I had an issue with locking, which led me to add ‘lock-never’ to gpg.conf.
I’ll leave the content below in case it helps with troubleshooting, other more advanced use-cases, or if it becomes relevant again in the future – perhaps there will come another time when one needs to use the official GnuPG builds with GPG4Win’s pinentry program.
The first thing I tried to fix this was to just install GnuPG 2.1.x for Windows (you can download it from gnupg.org), rather than Gpg4win. While this could find my keys (gpg -K), it didn’t let me decrypt anything because it doesn’t ship with a pinentry program. That comes with Gpg4win. I kept getting errors like this:
PS C:\> gpg --decrypt foo.txt.gpg gpg: encrypted with 4096-bit RSA key, ID ABCDE123, created 2015-01-01 "Foo Bar <firstname.lastname@example.org>" gpg: public key decryption failed: No pinentry gpg: decryption failed: No secret key
…until I found the following workaround:
- Install both GnuPG for Windows and Gpg4win.
- Update your system’s Path environment variable (under Control Panel -> System -> Advanced System Settings -> Environment Variables -> System Variables), and ensure that C:\Program Files (x86)\GnuPG\bin (GnuPG) comes before C:\Program Files (x86)\GNU\GnuPG\pub (Gpg4win).
- If you didn’t choose the default installation destinations, you need to take that into account of course.
- Kill any running gpg-agent.exe processes (just use the Windows Task Manager’s Processes tab)
- Run: gpg-agent.exe –pinentry-program ‘C:\Program Files (x86)\GNU\GnuPG\pinentry-qt4.exe’ –daemon
Now you can use gpg from PowerShell as before (e.g. gpg –decrypt mypasswords.txt.gpg | select-string google.com).
This workaround doesn’t make Kleopatra use the new GnuPG version, but at least the command line works again. If anyone knows how to get Kleopatra (and ideally the other tools that come with Gpg4win) to use the new GnuPG version, please do leave a comment.
Update on 20 June 2016: Added adjustments I had to make after a restart.
Update on 17 October 2017: GPG4Win 3.0.0 has been released