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>
pgpOD25ZWmyTr.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
