Page MenuHome GnuPG

Kleopatra: Multiple dirmngr started when searching for keys
Closed, ResolvedPublic


When testing T6830 we noticed that multiple dirmngr.exe were running after doing some searches.



Event Timeline

ikloecker renamed this task from Kleopatra: multiple dirmngr.exe started when searching for keys to Kleopatra: Multiple dirmngr started when searching for keys.Nov 23 2023, 4:14 PM
ikloecker added a subscriber: ikloecker.

High priority because multiple running dirmngr can cause interesting problems.

ikloecker changed the task status from Open to Testing.Nov 23 2023, 4:19 PM
ikloecker claimed this task.
ikloecker moved this task from Backlog to WiP on the vsd32 board.

Should work now.

With VS-Desktop- 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.

ebo added a project: Restricted Project.Nov 27 2023, 3:51 PM

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.

further improvement after the 3.2 release

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.

ebo changed the task status from Testing to Open.Nov 27 2023, 4:26 PM

I guess that the second instance is started by gpgsm_new (engine-gpgsm.c) via assuan_pipe_connect.

ikloecker added a subscriber: werner.

assuan_pipe_connect, etc., is outside of my comfort zone. Somebody else (@werner ?) should check how to prevent two gpgsm's started via gpgconf --launch and assuan_pipe_connect (if that's what happens).

werner moved this task from WiP to QA on the vsd32 board.
werner removed a project: vsd33.

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.

werner edited projects, added vsd32 (vsd-3.2.0); removed vsd32.
ebo reopened this task as Open.EditedJan 8 2024, 1:57 PM

It is still there in VS-Desktop- 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.

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

I propose to replace all backslashes in dirinfo with forward slashes so that GpgME always uses/returns paths with forward slashes. Or is there any reason for keeping the backslashes?

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

werner moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 9 2024, 10:14 AM

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

ikloecker changed the task status from Open to Testing.Jan 9 2024, 2:31 PM

Fixed in gpgme and gnupg 2.2/2.4.

ebo moved this task from Backlog to QA on the vsd33 board.
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 23 2024, 11:53 AM

works in Gpg4win-4.3.0-beta571

ebo removed a project: vsd33.

No more additional dirmngr.exe processes come up in VS-Desktop-, too.