I suspect that this has to do with your usage of tor (or gpg thinking that you use tor) because in dirmngr/dns-stuff.c I found

if (tor_mode)
  return gpg_error (GPG_ERR_NOT_ENABLED);

and all other places returning GPG_ERR_NOT_ENABLED seem to be related to S/MIME.

Lookup on server should no longer report any errors caused by a failed WKD lookup.

Does the recipient know the public key that was used for encryption?

Actually, noreturn isn't a keyword. The keyword is _Noreturn. noreturn is a convenience macro, which is provided in the header stdnoreturn.h. Funny enough, _Noreturn and the macro noreturn will be deprecated with C23 in favor of the new attribute [[noreturn]]. :-)
https://en.cppreference.com/w/c/language/_Noreturn

On Windows, it does now look like this:

The Certify action is now disabled everywhere for revoked and expired keys, i.e. in the main menu and the certificate list context menu, in the Certficate Details dialog, and in the Certifications dialog. Moreover, after importing a revoked or expired public OpenPGP key, the user isn't asked anymore whether they want to certify it.

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.

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.

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.

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.

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.

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.

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.

Fixed.

To debug this you can enable logging of the dirmngr (which does actually talk to the keyservers). To do so open GnuPG System/Network in Kleopatra's configuration dialog and set the debugging level to 4 - All and enter a filename for the log file.

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

I have implemented this a bit differently in particular with usability (e.g. discoverability of the import possibility) and accessibility in mind:

• Add a separate Import button instead of re-using the Sign/Encrypt button.

For one, this allows the user to encrypt a public key block. Moreover,
buttons that magically change their meaning are bad for accessibility.

• Update the three crypto operation buttons in one place.
• Disable the Verify/Decrypt button if the notepad is empty.

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

In T6085#162921, @aheinecke wrote:

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

After some discussion with Andre we decided:

1. We keep both buttons always enabled. Reasoning: We do not want to disallow a valid operation just because our heuristic says that attempting a decryption makes no sense.
2. Instead of the Encrypt button we switch the Decrypt button to Import if we detect a key block. This way the users can encrypt key blocks (which does make sense; in particular, for protecting exported secret keys), but attempting to decrypt a key block will always fail.

The long hint is "hidden" in the tooltip of the short hint.

And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

Should be fixed.

This is most likely a regression of switching to the gpgme-based secret key export.

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

Does the problem even occur if the secret key stubs have already been created?

I think this is mostly an issue during the setup of smart cards because Kleopatra lacks the functionality to delete the locally stored secret key without deleting the public key. Therefore, currently, it is necessary to delete secret and public key and then to re-import the public key.

inflateGetHeader does not seem to be called by anything from KDE. The only hits are from a copy of zlib included in marble.
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=inflateGetHeader

Please give a step-by-step description how to reproduce this.