Revisions and Commits
With VS-Desktop-22.214.171.1240-Beta I do not any more see more than one dirmngr for the test user who is not in the windows test-domain.
But I still see 2 processes for the domain user. Which is less than before. Task manager for all users:
It looks as if it could be one dirmngr.exe per user and per path given in the call to it. One with slashes and one with multiple backslashes.
Do we have different calls to dirmngr.exe where the form how the path is given differs? At least on windows?
The Domain user was the only one of the two who had a working keyserver configured.
One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.
When I do a search which is found on the keyserver, only the one without the multiple backslashes comes up, this seems to be started via gpgme call.
When starting again without a dirmngr and searching for a key which can only be found via WKD both entries appear in the taskmanager after only one search. The same is true if the key can be found in neither place. It seems the backslashes are associated with WKD and start is probably via gpgconf.
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).
Ingo's commit rM1bbe2d4b707 should fix this. Feel free to re-open iff you see more than one instance again.
It is still there in VS-Desktop-126.96.36.199 insofar as 2 dirmngrs are started. It was only fixed insofar that it is no longer more than 2.
With Keyserver set to "none" I see 2 dirmngr processes in the Windows task manager after one search, regardless of if something was found or not:
Edit: As it seemed to be relevant before: I did just now only test with the user who is not in the Windows domain. And I didn't start GpgOL at all, therefore it can have nothing to do with this.
Edit2: There are 2 dirmngr startet for the domain user, too, regardless of if the key is found on the configured keyserver or the WKD.
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.
The fix should go into gpgme to spawn dirmngr with a proper home directory (i.e with forward slashes). Further we can detect double quoting when set parse the --homedir option and fix this too in most cases. Bonus points for actually figuring out why quoting and unquoting does not work as expected.
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.