Page MenuHome GnuPG

gpg fails on Windows when specifying absolute homedir with drive letter
Closed, InvalidPublic

Description

I was in the middle of debugging an emacs problem, and ran into this today. I'm on Windows 11, runing gpg (GnuPG) 2.4.5 from msys64. The problem is that --homedir c:/foo/bar is treated as a relative path, as evidenced here:

% pwd
/c/Users/me/.config/emacs
% gpg --no-tty --status-fd 1 --yes --homedir c:/Users/me/.config/emacs/elpa/gnupg --command-fd 0 --import -- c:/emacs/emacs/share/emacs/30.0.50/etc/package-keyring.gpg
gpg: keyblock resource '/c/Users/me/.config/emacs/c:/Users/me/.config/emacs/elpa/gnupg/pubring.kbx': No such file or directory

As you can see from the last line, it's prepending my cwd to the --homedir arg. Since that begins with a drive letter, I think gnupg/gpg should treat it as absolute.

If I replace that path with --homedir /c/Users/me/... then it works OK.

I tested this in a msys2 shell and also in Powershell; the failure is the same in both cases.

Details

Version
2.4.5

Event Timeline

werner added a subscriber: werner.

pwd is not a standard Windows command. It is availabe in powershell but there I get

PS C:\c\Users\me\.config> pwd

Path
----
C:\c\Users\me\.config

I also get the expected output from gpgconf when setting a homedir:

PS C:\c\Users\me\.config> gpgconf --list-dirs --homedir c:/Users/me/.config/emacs homedir
c:/Users/me/.config/emacs

Thus I'd say that your GnuPG 2.4.5 from msys64 is some kind of Windows build using a Unix emulation. That may or may not work. Even if that works, I would not suggest this without first analyzing the entire random number code which has not been written for such a mixed platform.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.