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

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.