GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir

[Anton Shepelev]

Werner Koch:

> Anton Shepelev:
>
> > I observe this problem with GnuPG 2.42 -- the last
> > version that works on my Windows XP.
>
> Although 42 is in general a good answer, you probably
> mean GnuPG 2.4.2 released 3 years ago ;-)

Beg pardon for misinforming you, Werner.  I meant GnuPG
2.2.42.  It is the last version in which invoking
gpg.exe without parameters does /not/ fail with:

   > gpg
   gpg: WARNING: no command supplied.  Trying to guess what you mean ...
   gpg: Go ahead and type your message ...
   gpg: [stdin]: read error: Exec format error (ec=8)
   gpg: processing message failed: Unknown system error

Now I see that many later versions seems to work as
well, except for this bug when expecting stdin from the
console, which is rarely needed (if ever).  It still can
generate and edit keys interactively, after all.

> I think that even the current GnuPG version will work
> on XP SP3.

I cannot test it, having the 32-bit version of Windows
XP SP3.  Both the installer gnupg-w32-2.5.22_20260831.exe
and the binaries it contains require a 64-bit OS.

A few older versions seem to be 32-bit however, but they
fail to locate functions in DLLs:

   2.4.8: KERNEL32.dll:DeleteProcThreadAttributeList
   2.4.5: msvctrl.dll:_putenv

Could the absence of these functions on Windows XP be
handled gracefully?  While working on pixel-perfect
display for DOSBox, I had to support High-DPI awareness
in newer Windowses in order to prevent blurry
interpolaiton, while keeping the program compatible with
Windows XP.  IIRC, I achieved that with
GetProcAddress()[1], which returns the address of a
function is the DLL if it exports it, and NULL
otherwise.  Could something similar be used in GnuPG?
Simply checking the OS version is not so reliable,
because OneCore API[2] and other tricks can be used to
upgrade the API of Windows XP.

...That said, 2.4.4 works, except the aforementioned
stdin bug.  It also breaks when used with the pager,
however, as well as 2.2.42:

   C:\TEMP>gpg --version | more
   Not enough memory.
   :: ^ Who wrote the latter line -- gpg.exe or more.exe ?
   C:\TEMP>gpg --version > ver.txt
   C:\TEMP>type ver.txt | more
   gpg (GnuPG) 2.4.4
   libgcrypt 1.10.3
   Copyright (C) 2024 g10 Code GmbH
   ...

Ah, and gpg-agent is still unavaialble with a non-
standard home directory for 2.4.4.  References to this
error I have been able to find all agree that it occurs
when the GPGHOME environment variable is longer that
eighty-nine characters, e.g.:

   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206>
   <https://dev.gnupg.org/T4338>

But in my case it is only sixty-six characters long:
C:\Documents and Settings\Anton.GIT\Application Data\gnupg_test

> I think the problem you have is that you also copied
> the lock files maybe even with active locks and thus
> the stale lock file detection did not work.

I have tried creating a new homedir with `gpg --homedir
gnupg1 -k' instead of copyng my real one, and the error
persists.  Anyway, please instruct me how to copy a
GnuPG homedir to keep it working: shall I exclude the
.lock files?  Shall I test at some point that there are
no active locks?  If I shall, then how?

> gpg-connect-agent, like all other components, opens
> the file given by "gpgconf -L agent-socket", read the
> port number and the magic cookie, connect to that port
> on localhost and the agent checks that the cookie
> matches.

Although gpg respects my specified homedir gnupg_test:

   > gpg -k
   C:\Documents and Settings\Anton.GIT\Application Data\gnupg_test\work.kbx
   [...]

gpgconf still uses the default one:

   > gpgconf -L agent-socket
   C:\Documents and Settings\Anton.GIT\Local Settings\Application Data\gnupg\d.amintiqo51rit39k\S.gpg-agent

Can this be causing my problem?  Shall I restart the
computer after changing the home location?  Hardly...

> There are several ways to get the homedir, either
> using the envvar GNUPGHOME, a Registry entry, using
> the standard %APPDATA%upg, or using what an optional
> gpgconf.ctl side-by-side to the gpgconf.exe specifies.

I had already tried setting the registry entry for GnuPG
2.2.24, and it didn't work.  I don't have a copy of the
manual for that version (does not seem included in the
distubution!)  so maybe it was not yet implemented.  I
am using the environment variable now.

>   gpg --debug ipc -K
>
> also shows how the agent is accessed.

Here is what it prints for me, with a non-standard
homedir:

   > gpg --debug ipc -K
   gpg: reading options from 'C:/Documents and Settings/Anton.GIT/Application Data/gnupg_test/gpg.conf'
   gpg: reading options from '[cmdline]'
   gpg: enabled debug flags: ipc
   gpg: enabled compatibility flags:
   gpg: using pgp trust model
   gpg: no running gpg-agent - starting 'C:\\Program Files\\gnupg\\bin\\gpg-agent.exe'
   gpg: waiting for the agent to come up ... (5s)
   gpg: waiting for the agent to come up ... (4s)
   gpg: waiting for the agent to come up ... (3s)
   gpg: waiting for the agent to come up ... (2s)
   gpg: waiting for the agent to come up ... (1s)
   gpg: can't connect to the gpg-agent: Filename too long

No gpg-agent.exe appeared.
____________________

1. <https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress>
2. <https://theopenxp.org/wiki/OneCore_API>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260923/a71f31ca/attachment.sig>