Awesome, thanks all! From an end user perspective that would be a perfectly acceptable outcome, the warning just serves to confuse people. Appreciate the help!

I have created the spin-off T6202: Kleopatra: Suppress errors of WKD lookups to deal with not bothering Kleopatra's users with error messages when doing a WKD lookup in the background. This task is for improving dirmngr.

keyboxd has nothing to do with this, it merely makes the lookup of keys a bit faster. The computation of the WoT itself takes long and there is no shortcut for it. Fortunately most users don't have a deeply meshed WoT with dedicated revokers etc., thus for them things are fast in the standard configuration.

works now

I agree. We have to get rid of auto check trustdb and such stuff. I always found that impossible to program around because it either takes a long time (check-trustdb) or it might return invalid results (no check).
The solution for this is keyboxd.

If you run gpg --export-ownertrust you will notice that the trust has been set to ultimate (value is 6). However, due to the no-auto-check-trustdb in your gpg.conf that will valeu will only be shown after running gpg --check-trustdb. The value shown in the key listing is the computed value and the computation is done by --check-trustdb. I don't see a bug here.

I see what I can do

Real Passphrase is "test"

The workaround is easy: Change the passphrase , export, import and then set a longer passphrase again.

In T6014#163086, @ikloecker wrote:

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Can you give an example other than the Syntax error issue? So far, I haven't seen any errors when doing random searches with ASCII-only "email addresses". I simply get zero results, but I don't see error messages, e.g. if the host cannot be found.

Pushed changes.

Note that, we cannot use enum values in CPP constant expression like:

# if GPG_ERR_SOURCE_DEFAULT != GPG_ERR_SOURCE_KEYBOX

That's because CPP has no way to know enum values.

If the certificate details are opened from the Lookup on Server dialog for OpenPGP keys that are not already present in the local key ring, then all buttons and context menu entries that don't make sense should be disabled or hidden. Information that cannot
be determined for remote keys (e.g. the expiration date of keys looked up on keyservers) should be hidden or displayed as
"unknown".

The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Of course it could be refined to use the same host if there is only a relative URL.

That's for sure. See rGfa1b1eaa4241ff3 :

Does dirmngr maybe interpret the redirect reply /.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/ as URI? That would explain the error because without protocol the redirect reply is indeed an invalid URI.

Let me know if you want full logs, but here is the segment with more info.

All commands should work as before (or more robust if a key listing happens while the command is running). Setting to resolved because there isn't anything that can or should be tested specifically.

@ametzler1 thanks for the feedback!

Now "BER error" is reported, if the user tries to import a .p8 certificate. (The certificate exported by Kleopatra wasn't stored as PKCS#12, but presumably as PKCS#8 which gpgsm cannot import. See T6189: Secret key backup of S/MIME certificate creates bad result.)

This was broken by a regression in the P12 parsing code.

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Thanks for your help analysing this problem.

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

There is probably an umlaut or special character in <domain> or <user> which makes the URL invalid. If I search for "test@ä.de" I also get Syntax error in URI.

--import [files]
       Import  the certificates from the PEM or binary encoded files as well as from signed-only messages.
       This command may also be used to import a secret key from a PKCS#12 file.

Mh, this has not changed anything for me. With GnuPG 2.3.8-beta32 i get either Invalid Object or no error at all. With this certificate

So looking through the logs it appears that it is trying a lookup against our domain, in addition to the key server we have configured.

That would make sense on a Linux desktop. But my main use case for this is Windows. I have the feeling that more Linux users have a decent MUA.
If we had a MUA with good MIME Support then we would not need this feature at all. If a user has Outlook for example that could be used with GpgOL but not everyone has that. I know that some users decrypt such messages already with Kleopatra and then open the Output in Thunderbird. But again, if they had Thunderbird, they could use that with included PGP/MIME support.
Windows 10 has a default Mail app, but if you open a file with that it does not show it but asks you to configure an account.

Wouldn't it make more sense to pass the decrypted text back (wrapped into a minimal rfc2822 message) to a MUA if it turns out to be another MIME tree with attachments and what not? After all, parsing and showing MIME trees is what MUAs are really good at and many MUAs should be able to open an .eml file.

Instead of using KDE for MIME parsing, and as I would also only do simple parsing we could use the mimeparser from gpgol. This also has the advantage that we do not open new attack surfaces as we already have that code in use. The mimedataprovider can already be compiled on Linux and used with a FILE, I did this to allow fuzzing for it. And the API implements the GpgME::DataProvider interface https://dev.gnupg.org/source/gpgol/browse/master/src/mimedataprovider.h and then just offers simple functions to access the parsed content.

If any notepad operation is canceled, then there shouldn't be any error messages or result widgets (the frame with the Close button in the screen shots) anymore.

If we would provide Gpg4win-3.1.24 also in binary form we would make it harder for us to argue that VS-NfD users have to purchase GnuPG VS-Desktop with the required support