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

Fixed.

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.

For Gpg4win we will soon release a 4.0.4 Version that will contain the latest Kleopatra updates and GnuPG 2.3.x, but the 3.1.x series of Gpg4win is something that we only release in binary form as part of our Product GnuPG VS-Desktop.
The reason for this is that for VS-NfD there are some responsibilities for the supplier, and so the VS-NfD user needs a responsible supplier. We do not promise that for Gpg4win, which is the free community version anyone can download. 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.

Checking musl internal, it seems that we can detect a single threaded application by:
https://git.musl-libc.org/cgit/musl/tree/src/internal/libc.h#n22

Thanks for your help @gniibe and apologies for wasting your time. It looks like this is an issue with ncurses on musl systems and I'll pursue it there. I have a patch to their configure which works & fixes building pinentry.

I've reported it on bug-ncurses@ to get some insight: https://marc.info/?l=ncurses-bug&m=166268018624805&w=2.

Mysteriously, I get nothing:

$ pkg-config --cflags nurses

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.

Ah OK I'm following now, I had took that as maybe another lookup at that time was failing. The keyserver that we have configured is hkps://keys.openpgp.org. Is there any misconfiguration here with that setting?

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

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.