Windows, ELPA, gnupg and keys problems

[SOLVED: SEE BELOW RE: GNUPG FOR WINDOWS] Good morning. I'm currently in hell with gnupg and the package archive contents issue. I'm in Windows, I know that's not everyone's preferred OS for this, but it's what I'm using and I've done well with the emacs 28.1 built for Windows. Listing packages now causes an archive error: Failed to verify signature archive-contents.sig: No public key for 066DAFCB81E42C40 created at 2022-11-05T04:10:05-0500 using RSA Command output: gpg: keyblock resource '/c/Program Files/Emacs/c:/Users/remil/.emacs.d/elpa/gnupg/pubring.kbx': No such file or directory gpg: Signature made Sat Nov 5 04:10:05 2022 CDT gpg: using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 gpg: Can't check signature: No public key Now, I have run the commands for this that should have updated it: PS C:\Users\remil> gpg --homedir ./.emacs.d/elpa/gnupg --receive-keys 066DAFCB81E42C40 gpg: keybox '/c/Users/remil/./.emacs.d/elpa/gnupg/pubring.kbx' created gpg: /c/Users/remil/./.emacs.d/elpa/gnupg/trustdb.gpg: trustdb created gpg: key 066DAFCB81E42C40: public key "GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org>" imported gpg: Total number processed: 1 gpg: imported: 1 And I can verify that gnupg set things up: PS C:\Users\remil\.emacs.d\elpa\gnupg> ls Directory: C:\Users\remil\.emacs.d\elpa\gnupg Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 11/5/2022 11:56 AM crls.d d---- 11/5/2022 11:56 AM private-keys-v1.d -a--- 11/5/2022 11:56 AM 1108 pubring.kbx -a--- 11/5/2022 11:56 AM 32 pubring.kbx~ -a--s 11/5/2022 11:56 AM 54 S.dirmngr -a--s 11/5/2022 11:56 AM 54 S.gpg-agent -a--s 11/5/2022 11:56 AM 54 S.gpg-agent.browser -a--s 11/5/2022 11:56 AM 54 S.gpg-agent.extra -a--s 11/5/2022 11:56 AM 54 S.gpg-agent.ssh -a--- 11/5/2022 11:56 AM 1200 trustdb.gpg But the problem persists no matter what solution I try EXCEPT for turning off package signature checks completely which is generally a bad idea. Does anyone know what's going on? My guess is that it's that truly hideous path that Emacs tried to find the key at but that might be an OS issue -- not entirely sure how to fix that. I have HOME set to c:/users/remil/ which is where I have .emacs.d and other things and that works adequately, but this gnupg thing is driving me bonkers. Any ideas out there? Greatly appreciate it!

I have a different gnupg issue with emacs on windows, and found that the GnuPG user mailing list is helpful. There is also [dev.gnupg.org](https://dev.gnupg.org) which has useful answers on it.

Smells like antivirus to me .. or some sort of firewall

Can't be this. As I noted, I can successfully execute the gpg command and retrieve it. Firewall would be indiscriminate. Doubtful about antivirus as well. This seems like an OS path issue I think.

Firewall might have certain programs whitelisted … gpg might be known to be good. I had similar issues trying to install MSYS a while ago. AV would just delete the certs that the package manager used.

I'm thinking it's a path creation method, but I don't know how to break into it. That path that gpg reports as its destination for the keyring: /c/Program Files/Emacs/c:/Users/remil/.emacs.d/elpa/gnupg/pubring.kbx Looks very iffy to me. I can verify that that keyring has the key in it. I tried listing the keys for that location: PS C:\Users\remil> gpg --homedir .\.emacs.d\elpa\gnupg --list-keys /c/Users/remil/.\.emacs.d\elpa\gnupg/pubring.kbx ------------------------------------------------ pub rsa3072 2019-04-23 [SC] [expires: 2024-04-21] C433554766D3DDC64221BFAA066DAFCB81E42C40 uid [ unknown] GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org> So it's there, but the path Emacs creates for gpg is absolute nonsense. It's starting with the installation location for Emacs for Windows, then tacking on HOME (defined as c:/users/remil/) then tacks on .emacs.d/elpa/gnupg. I think this is not a firewall or antivirus issue. it's solidly a Emacs and Windows interaction. Still investigating.

Almost absolutely a path issue I'm sure. I tried an experiment PS C:\Users\remil> gpg --homedir C:\users\remil\.emacs.d\elpa\gnupg --list-keys gpg: keyblock resource '/c/Users/remil/C:\users\remil\.emacs.d\elpa\gnupg/pubring.kbx': No such file or directory gpg: Fatal: /c/Users/remil/C:\users\remil\.emacs.d\elpa\gnupg: directory does not exist! PS C:\Users\remil> gpg --homedir /c/users/remil/.emacs.d/elpa/gnupg --list-keys /c/users/remil/.emacs.d/elpa/gnupg/pubring.kbx ---------------------------------------------- pub rsa3072 2019-04-23 [SC] [expires: 2024-04-21] C433554766D3DDC64221BFAA066DAFCB81E42C40 uid [ unknown] GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org> The first is the path I thought Emacs might try to craft for the ELPA gnupg directory. Basically $HOME and the Emacs directories it expects. Look at what gpg says for the resource name! The second is where I took the resource name it created and then tried to guess how it would expect to see a Windows pathname Unixified, and it worked. Now if I can figure out how to fix it I'll be home free.

SOLVED! In case anyone run into this same problem, here's what happened. I had installed MSYS2 on my machine as well. I like Unixy utilities even though I'm in Windows OS. Well the MSYS2 compilation includes POSIX path mangling, or demangling, or ... something. Basically it's trying to convert things. The path Emacs was providing was almost certainly my Windows environment HOME as `C:/Users/<name> which works for everything Windows likes but nothing POSIX likes. The solution was to download GnuPG for Windows and make sure the bin directory precedes the MSYS2 directory in the path. With that in place, the regular Windows pathing works: PS C:\Users\remil> Get-Command gpg CommandType Name Version Source ----------- ---- ------- ------ Application gpg.exe 2.3.8.284… C:\Program Files (x86)\Gpg4win\..\GnuPG\… PS C:\Users\remil> gpg --homedir C:\users\remil\.emacs.d\elpa\gnupg --list-keys C:\users\remil\.emacs.d\elpa\gnupg\pubring.kbx ---------------------------------------------- pub rsa3072 2019-04-23 [SC] [expires: 2024-04-21] C433554766D3DDC64221BFAA066DAFCB81E42C40 uid [ unknown] GNU ELPA Signing Agent (2019) <elpasign@elpa.gnu.org> pub dsa2048 2014-09-24 [SC] [expired: 2019-09-23] CA442C00F91774F17F59D9B0474F05837FBDEF9B uid [ expired] GNU ELPA Signing Agent (2014) <elpasign@elpa.gnu.org>

Nice use of sky blue in this notification mate

You mean the fixed-width text? Thanks. I tend to find posts that actually put code and terminal I/O in fixed a lot more readable.

Wanted to comment and say thank you very much for posting this solution. I ran into the exact same scenario after recently installing MSYS2, and you just saved me a TON of troubleshooting time. Cheers!

You're very welcome. I always hate it when I find that someone is having the same issue, but then it's swept under the rug.