Maybe those smime certs will do:

It needs to be clarified which kind of errors should be handled and which kind of S/MIME certificates should be allowed to be used for encryption:

• Valid certificates where the CRL check (or OCSP check?) fails
• Invalid certificates (e.g. because of incomplete chain/missing CA)
• Expired certificates

Pushed the change: rG533bcc265e9c: common:dotlock: Clean up for error/info/warning message.

While I pushed the change of libgcrypt, I'd like to apply following change to GnuPG.
This is more kind than GPG_ERR_BAD_PASSPHRASE by gcry_pk_testkey failure.

Do we have a test certificate for this? The certificate in T6702#176845 is expired.

After talking to Werner I lower the prio as apparently there is no direct customer request for this

I retract my patch in T8171#215603

@m.eik gave us this link: https://github.com/ProtonMail/go-crypto/issues/184

To clarify, the state in Kleopatra Ingo described a year ago has changed, with T7579: Kleopatra: improve menu items the refresh option in the Tools menu was removed. Both actions to update certificates - in the context menu and in the details - are/work the same.

Just a quick note: I wouldn't remove the gtk-2 pinentry unless you have made sure that all still supported long-term enterprise distributions (RHEL, SLES, Debian, ...) support something newer. I have kept the Qt 4 pinentry although Qt 4 is obsolete since ages because some people still used it.

Removing kleopatra tag since Kleopatra already does what's requested.

But the original patch rG1b4ac98de7db: agent: Accept a trustlist with a missing LF at the end. was not working to allow missing newlines in gpg4win-5.0.0 @ win11?

Extended to show distinct messages for the cases:

It had already fixed in: rG55b5928099ba: dirmngr: Change the default keyserver.
And then in: rGa2f2523b99ff: Remove the default keyserver.

With same reason for T3852, I close this ticket.

GPGME has been divided into new GpgME, QGpgme, GpgMEpp, and GpgME-python.
And new QGpgme uses CMake now.