Fixed in gpgme and gnupg 2.2/2.4.

This is due to the changed format of the VERSION file.

I applied a fix to gnupg which also solves the issue.

Taking over

We did this on purpose once - For Windows ppl it is just weird to see forward slashes.

In T6833#181135, @werner wrote:

The fix should go into gpgme to spawn dirmngr with a proper home directory (i.e with forward slashes).

I think the double backslash quoting happens because _gpgme_io_spawn quotes the backslashes and calls gpgme-w32spawn and then gpgme-w32spawn quotes the backslashes again and calls gpgconf. I haven't seen anything in gpgme-w32spawn that would unquote the quotes backslashes. But maybe that's supposed to happen in the background. A comment in the code reads "We have to quote some things because under Windows the program parses the commandline and does some unquoting.", but maybe that's no longer true.

Double backslash quoting is the culprit. For WKD requests the GPGMe QT code makes sure that the dirmngr has been started. This is done by running gpgconf --homedir FOO --launch dirmngr. gpgconf returns the homedir with backslashes on Windows to be be nice to ppl who wonder when they notice (legal) forward slashes on Windowns. Now when the spawn function along with its helper is called, it needs to quote the backslashes. But somewhere on the way back one de-quoting is missing and thus gpg sees double backslashes. That is in general not a problem but when checking whether this is the standard home directory, this does not match and gpg puts the socket into a subdirectory. In turn another dirmngr is started for the WKD purpose.

Merged.

Yeah we should do an ntbtls release. As a core library it does no matter much which workboard we use. Let's remove it the vsd tag.

It is still there in VS-Desktop-3.2.1.0 insofar as 2 dirmngrs are started. It was only fixed insofar that it is no longer more than 2.

It does not matter how many gpgsm instances try to start a daemon. The same code is used for starting and this code first takes a lock. When using gpgconf --launch the same code is used too (indirect by calling gpg-connect-agent NOP /bye wityh options for the respective daemon).

Looks good.

Since this is hard / impossible to test for, but the fix was obvious I am closing this directly. The fix for this is in GpgOL 2.5.12.

For the record. The code used to detect early on if the dark or bright icon theme should be loaded as a resource caused a crash during startup on at least Windows Server 2016 Enterprise. Our new fix avoids such API but I have created T6921: Kleopatra / Qt6: Improve accessibility detection for "Desert" high contrast scheme and fix it upstream to keep track of this since our fix is not fully complete in that it does not properly detect the Bright (Desert) High contrast mode and it should either be merged into KIconThemes or fixed in / with Qt6.