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.

Backported for VSD 3.4

Should be backported to VSD 3.4 because these changes amend T7212: Problems with certificate colors / styles.

Backported for VSD 3.4

The remaining open points of this ticket will be "won't fix" for now. When we plan to change something here, we should open new tickets, this one got confusing.

I put the new menu entries below the menu entry for the Quick Guide into the Help menu.

Done. And backported for VSD 3.4.

Note: I noticed that most of the old documents use underscores instead of hyphens in the document names. It doesn't really matter, but being consistent makes it easier to avoid typos.

Backported for VSD 3.4

To avoid confusion the outer folder is now kept if the name of the archived folder doesn't match the name of the archive.

Sound sensible. Ok, then this ticket will only revert T8022 for archives which were renamed.

1. That the users focus on the documentation which is more important for them.
2. That the menu is not too long. This point will be +/- moot now but removing "more documentation" now would make extra work.

And 1) stays valid. So I'd keep it in place until all the new documentation is available. Unless @ikloecker sees this differently

Good point! Just to clarify: there are several chapters that appear in both the User Manual and the Administrator Manual, each with a different focus. Smartcards, Backup, and Trust Management are topics covered in both.

It is clearly not implemented for S/MIME: rKLEOPATRA9eed4a45ed93 but it should be.

It's not that simple. The user could have decrypted multiple archives. Showing an additional message box after all decrypted archives have been moved to the final destination somehow doesn't feel right. And what if an archive and a regular file were decrypted? Should the additional message box also show the final destination of the regular file? I think this needs more thought.

Please keep in mind, that for the 3.4 release, we will most likely only have the User Manual ready, not sure about the Administrator Manual.

Alternative suggestion:

added vsd34 for the resetting of the defaults

I can't reproduce this on gpg4win-5.0.2-beta2 and vsd-3.3.4.

Q3 is T7650: Kleopatra: Limit width of KMessageBoxes

ok, lets go with the message box.

Q1 stays like it is, for Q3 @tfry made a merge request to wrap after 120 characters. Please add a link to this.

We need a test $GNUPGHOME with different secret keys to test this scenario:

• expired key
• 2 usable keys (not expired)

Marcus suggestion: offer the HTML mail content as attachment.

A message box would be fine.

It's impossible to know beforehand (i.e. before the user clicked Save) how the folder is going to be called because it might get a suffix to avoid a collision and this cannot be checked before the user clicks Save. I suggest to remove the useless information where the archive was extracted because it's a temporary location. Instead we could add a message box which tells the user the actual location after the data was moved there.

I've created the ticket above for Q2, we need to discuss how to follow up Q1 and Q3 next week.

as T8022 was backported, this one should be backported, too, if possible. I'll add the tag

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

In T7502#214891, @ebo wrote:

Q3: Would you make the text in "Certify shared secret key?" wrap?

In T7502#214891, @ebo wrote:

Q2: For 2 and 3 "Certify new certificate? You have imported an new certificate (public key) […]" is not strictly correct, this could be confusing. Maybe we could use the "Certify shared secret key?" instead and change it a bit to make it fit this case too? How about starting with:
"You have imported a shared secret key / a key without primary part." And then leave out the "shared" in the second sentence and in the window title.

In T7502#214891, @ebo wrote:

Q1: Does showing the "Detailed results of importing" make sense for the above cases? One could argue that we could remove it for all single imports where any dialog is shown.

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

this comment was intended for T7581, moved it to there.

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

The case above shows the case where the public key for the imported secret key was in the keyring beforehand.
We'll assume that this is something which would probably not occur in real life and don't explicitly handle this.