Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.

Tested this some time ago.

Better don't remove your entire ~/.gnupg - removing the *.lock files after gpgconf -K all is sufficient.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

This either requires an updated libassuan which allows "INPUT FILE=foo" in addition to INPUT FD=n" or using custom handlers in for INPUT et al. in gpgsm. I'd prefer the former. Anoter option would be to open and close the file in ggpgme and pass the fd.

Already done with rG89c7eccba51554 which will be in the next VSD release.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.

Possible reason: There's a kleopatra.svg in breeze-icons/icons, but there's none in breeze-icons/icons-dark.

The problem has been addressed for all OpenPGP crypto operations on files.

This is currently not possible (blocked by T6927: gpgsm: Accept file names for input and output in server mode).

I was wondering whether "Exec=pinentry" should be "Exec=pinentry-qt" because "pinentry" could be a symlink to another pinentry. On the other hand, we probably want to use the same icon also for pinentry-gtk, etc.

Thanks for the contribution, sorry this took us a while to get to. I've merged your changes to the pinentry repo now.

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.