Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

Hi, it would be great to make Kleopatra remember the last used settings.

Thank you for your time and your answer, we really do appreciate your work. We invested in this in hope to help make the software better. Please try it, so you will see how it works. We were able to reproduce the problem the way I described. When installed as a normal user it won't work. Installed as an Administrator user it works. So the more secure way does not work currently.

The way how you install it can have nothing to do with that, it must be a different issue, but it sounds to me like you are messing with privileges a bit too much. Did you ever receive the warning of Kleopatra that you are running it as Administrator and that will mess up the rights in your GnuPG folder? Be honest. :)

You mean if you right click on a file and select sign & encrypt or if you choose the action from Kleopatra?

For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.

PR that removes the "Show key details" link from the response email: https://invent.kde.org/pim/kdepim-addons/-/merge_requests/37

It took a bit of time to set things up, but I was able to manually perform the WKS dance and open each email in KMail to check how it works.

This looks to me like the typical thing where you also do not get the "Diagnostics" button viewed. Because log-file is set in the various .conf files and the stderr does not get back to GPGME / Kleopatra so we have nothing to show there because the actual error ended up in a log file.

In T5960#175407, @ebo wrote:

The result of your changes is a bit unexpected for me, maybe something is missing in the testversion Gpg4win-4.2.1-beta31?

[6064] org.kde.pim.libkleo: gpgConfGetConsoleOutputCodePage returns 65001
[6064] org.kde.pim.libkleo: stringFromGpgOutput trying to decode "" using codepage 65001

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

Also fixed for gnupg22

My issue was that it makes no sense to publish a revocation of a local certification...
I'm fine with it in the case if the certification was exportable.

Btw. if the keyserver is set to "none" or whatever the new value is worded we should remove all the publishing options from the UI. But that is a different issue, I just noticed this while talking about this ticket.

If I revoke a certificcation I am asked to "publish revocation".
When certifying there is the checkbox to publish.

Tested with current version. Works.

this works now:

I think using a static const char * is better than using a macro. In fact, using a static constexpr std::string may be even better because we avoid calculating the string length during runtime again and again. (I'm not sure the compiler is clever enough to precalculate the string length of a static const char *.)

Tested at first with GnuPG-VS-Desktop-3.2.0.0-beta178 from 2023-08-29

@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory