No error message in that case for Gpg4win 4.4.o either

This is about attachments of encrypted emails opened with the mail viewer that Carl wrote. If one opens those attachments with an external application then the decrypted attachments are written to temporary files. I don't see that this has anything to do with Kleopatra (unless the mail viewer is considered part of Kleopatra which, technically, it isn't).

QA would like to now what exactly to test here… if there is a succinct description of that in a ticket, it will get tested at the very least sooner. Or at all.

works with Gpg4win 4.4.0, too

Should definitely work with gpg4win if it works with vsd.

That was resolved with vsd 3.2.0

To clarify: this works for "Restart background processes" only, as was the aim of this ticket

forgot to keep it open for test with gpg 2.4 branch versions...

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

Works on Gpg4win 4.3.1, too.

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

Note to self: The error message that nothing was found on the keyserver will still come up if one is configured. That will be fixed with T6493.

The certificates from the same test smart card work in Version 3.2.2.231170 (Gpg4win-4.3.1), too, but there all certificates are shown, that is one more than in the VSD version. Seems gpg2.4 can handle certificates which 2.2 does not accept. But that is nothing to complain about.

Arghh, a GPGME_DEBUG=3 which shows basic I/O preparation does not exhibit the bug.

Fixing gpg is easy but there is some bug lingering in gpgme which might be a recent regression. An strace shows

Hidden for Gpg4win-4.3.0-beta571, too

works in Gpg4win-4.3.0-beta571

Fixed in gpgme and gnupg 2.2/2.4.

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.