Skip to content

Conversation

@chawyehsu
Copy link

When GnuPG is built for MSYS2 (e.g., as part of Git for Windows), it expects
the GNUPGHOME environment variable to contain a POSIX-style path
(e.g., /c/Users/user/.gnupg). However, users often set this variable using a
Windows-style path (e.g., C:\Users\user\.gnupg), which is the native format
for GnuPG for Windows.

This discrepancy leads to MSYS2-based GnuPG failing to correctly locate its home
directory when running within an environment having the GNUPGHOME defined in
the Windows-style, as the Windows path is not properly interpreted. This issue
prevents users from seamlessly sharing a single GnuPG home directory across
different GnuPG installations (native Windows build vs. MSYS2-based). 1 2

To resolve this, we posix-ify GNUPGHOME in a manner similar to SHELL. 3
This change will allow MSYS2-based GnuPG to correctly interpret the GNUPGHOME
variable regardless of whether it's set with a Windows path, improving the
interoperability and user experience.

Issue 4 and 5 from git-for-windows should benefit from this change.

This addresses #297

When GnuPG is built for MSYS2 (e.g., as part of Git for Windows), it expects
the `GNUPGHOME` environment variable to contain a POSIX-style path
(e.g., `/c/Users/user/.gnupg`). However, users often set this variable using a
Windows-style path (e.g., `C:\Users\user\.gnupg`), which is the native format
for GnuPG for Windows.

This discrepancy leads to MSYS2-based GnuPG failing to correctly locate its home
directory when running within an environment having the `GNUPGHOME` defined in
the Windows-style, as the Windows path is not properly interpreted. This issue
prevents users from seamlessly sharing a single GnuPG home directory across
different GnuPG installations (native Windows build vs. MSYS2-based). [1] [2]

To resolve this, we posix-ify `GNUPGHOME` in a manner similar to `SHELL`. [3]
This change will allow MSYS2-based GnuPG to correctly interpret the `GNUPGHOME`
variable regardless of whether it's set with a Windows path, improving the
interoperability and user experience.

Issue [4] and [5] from git-for-windows should benefit from this change.

[1]: https://lists.gnupg.org/pipermail/gnupg-users/2025-February/067533.html
[2]: https://lists.gnupg.org/pipermail/gnupg-users/2025-March/067538.html
[3]: msys2@8bb4359
[4]: git-for-windows/git#5607
[5]: git-for-windows/git#3857

Signed-off-by: Chawye Hsu <[email protected]>
@jeremyd2019
Copy link
Member

Has anyone considered that win32 gpg and cygwin gpg won't be able to talk to each other? cygwin will be using their unix sockets, and has its own pid namespace, so it seems likely that you could get two different gpg-agents and/or dirmngrs running on the same GNUPGHOME, and I don't know what sort of issues that could cause.

@dscho
Copy link
Collaborator

dscho commented Jul 10, 2025

win32 gpg and cygwin gpg won't be able to talk to each other

That's a really good point I had not considered before.

My thinking involved the keyring only, which should be able to be shared. @chawyehsu could you test what happens when you start a Win32 GPG agent and try to use it via the MSYS2 GPG, and also what happens when you start an MSYS2 GPG agent and try to use it via Win32 GPG? (You should be able to perform these tests by installing mingw-w64-x86_64-gnupg and gnupg side by side.)

@jeremyd2019
Copy link
Member

I seem to remember that mingw-w64-gnupg didn't actually work right... probably better to use gpg4win.org (or the win32 package of gnupg)

I was thinking, maybe gnupg needs the same sort of treatment as ssh (do you want to use the msys2 version or the win32 version?), though I hate the idea of yet another GfW installer option

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants