Unable to override gnugpghome from python-gnupg

[dwoz]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

There seems to have been some sort of regression in `2.51.0.windows.2`. We have some tests in our testsuite that override gnupghome when instantiating python-gnupg.

`gpg: keyblock resource '/c/Users/dan/src/salt/C:\\\\Users\\\\dan\\\\AppData\\\\Local\\\\Temp\\\\pytest-of-dan\\\\pytest-15\\\\test_gpg_absent_test_mode_no_c0\\\\gpghome/pubring.kbx': No such file or directory`

This same code works on version `2.51.0.windows.2`

I found a similar issue on stack overflow from a while back:
https://stackoverflow.com/questions/52661839/gpg-keyblock-resource-pubring-kbx-not-found-because-the-repo-path-is-prefixed-t

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Options set during installation

Installed via windows package with all of the default options.

Other interesting things

No response

Terminal/shell

powershell.exe

Commands that trigger the issue

keys = [...]
gnupghome = r"C:\tmp\foo"
gnupg = gnupglib.GPG(gnupghome=gnupghome, verbose=True)
gnupg.import_keys(keys)

Expected behaviour

gnupghome should be honored correctly.

Actual behaviour

We get some weird concatenated home:

'/c/Users/dan/src/salt/C:\\Users\\dan\\AppData\\Local\\Temp\\pytest-of-dan\\pytest-15\\test_gpg_absent_test_mode_no_c0\\gpghome/pubring.kbx'

Repository

https://github.com/saltstack/salt/actions/runs/18427900591/job/52520127411?pr=68352

[rimrul]

There seems to have been some sort of regression in 2.51.0.windows.2.
[…]
This same code works on version 2.51.0.windows.2

There seems to be some copy & paste error here.

gnupghome = r"C:\tmp\foo"

I don't think that ever worked with our gpg.

Edit: I think I've been wrong about that. See git-for-windows/MSYS2-packages#33

Our gpg expects a path in the style /c/tmp/foo. There has been discussion about converting it, but I think the current opinion is that it would be deeply flawed.

"Mixed" path style (i.e. C:/tmp/foo) might work, though.