As I'd like to have it in vsd34, I'll set that tag (and of course gpd5x, too)

Implemented for the Notepad and Sign/Encrypt Files. Can be tested with the certificates in T6702#216065.

Looks good to me on vsd-3.3.7-beta90.9 @ win10:

Seems I forgot to note that icon removal works when resetting to defaults. And the VSD related Categories are no longer shown in Gpg4win. Tested now with Gpg4win 5.0.2, but I believe it was already ok in 5.0.0.

Maybe. EncryptionResult has a list of invalid recipients and I've changed the code to show the Retry dialog only if there's at least one invalid recipient.

Your suggestion sounds ok to me, maybe with a slight change for the message: "Failed to encrypt the notepad because at least on certificate could not be validated."

I tried to add the list of invalid recipients to the message box, but it seems that gpgsm stops the validation of the certificates at the first invalid recipient. I got only the first Bob certificate reported as invalid recipient when I tried to encrypt to both Bob certificates so that it doesn't make sense to list the (incomplete) list of invalid recipients. It also means that Kleopatra cannot update the invalid recipient certificates because it knows only of one invalid certificate.

Ideally the certificate would change, but Kleopatra has no idea that this certificate turned out to be not valid. In fact, Kleopatra doesn't even know that the encryption failed because of some certificate. It could have failed for any other reason (e.g. full disk). Kleopatra only knows that an error occurred and offers to retry with lower security. (I looked at GpgOL and it does the same.)

yes, basically it's what we want.

Current implementation for the case of an S/MIME certificate which turns out to be invalid when it's used for encryption. Is that what we want?

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

Issue 1) should be implemented as already described (on error -> dialog to retry with "always trust" flag)

@ebo and me talked about this and T6701: GpgOL: Use GPGME_ENCRYPT_ALWAYS_TRUST. We think, it's best to have a short meeting to discuss further changes.

I have added the fix as patch for VSD 3.3 because the commits that introduced this regression were also added as patches for VSD 3.3.

This is a regression that was introduced with T7759: Kleopatra: Notepad encryption with S/MIME fails.

Fixed. For VSD 3.4 this will also be fixed if gpgme is updated.

This is a bug in gpgme. gpgsm_assuan_simple_command only reads a single line before waiting for more data although there is a second line (ERR ...) ready to be read. gpgsm never sends more data because it has already sent its full answer. So gpgme waits forever.

Ticket for the hang on file encryption: T8187: Kleopatra: File encryption with invalid S/MIME certificate hangs indefinitely

According to Werner, that should be:

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

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