ok, neither is a no-brainer, i see. But I would vote for the left to right order, i.e. the alternative you mention. This has the advantage that the card type is listed on the left side with which one can maybe better identify the card. In my example the type is "Yubico OpenPGP-v.3.4-card", I do not see the info that it is a Yubikey anywhere else. Therefore a blind user will only get that info up front if the left side is read first.

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?

feedback of @mmontkowski needed

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.

Patch was merged upstream (KF 6.25): 332678d8a4f635d6938eb3e9ec03d845aa89697a

I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

With signing only, the retry option is not offered and directly either hangs or shows the "Invalid CRL object" / "Unknown error" error.
Is this intentional?

Here is an attempt to fix the client side:

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.

Note that KWatchGnuPG isn't available on Windows.

Fixed. KWatchGnuPG doesn't modify GnuPG config files anymore. Instead one has to set socket:// as log file for the components one wants to see in KWatchGnuPG.

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

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

Pushed the change of gpgme: rM8b89678aed6d: Fix passphrase cancel handling.

Pushed the last change: rG2239f687bb14: scd:openpgp: UI improvement for use of PIN-entry.

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.

Done.

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

This is a bit larger change (of UI improvement):

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.

I consider again about Ben's change. It could be simply support of the detection of the cancel situation where gpgme should return GPG_ERR_CANCELED (not related to single cancellation vs. whole cancellation).

I can't remember why Ben introduced the new status. OTOH, I wish that the Qt-Pinentry also emits a button_info line for closing the window. Normal users don't notice the difference but if you have a lot of private keys and you get a mail which has only hidden recipients the full_canceled is pretty useful. Also for other tasks like allow-mark-trusted: On Windows with the qt-pinentry I am always cursing about this but on my box I only need to close the pinentry window to get a fully_canceled

added vsd34 for the resetting of the defaults

I investigated the introduction of STATUS_CANCELED_BY_USER and GPGME_STATUS_CANCELED_BY_USER:
rG31e47dfad0f4: gpg: Add canceled status message.
rM35ca460019ea: Parse STATUS_CANCELED_BY_USER.

Filter 16 is the new filter for valid certificates. The problem could be that the version you tested did not yet have this filter.

@ikloecker I'd like it if we could backport the resetting of the preferences to vsd34.

Font selection dialog lets the user choose a font size, which is then not respected - can we disable selecting the font size?

I cannot reproduce this on gpg4win-5.0.2-beta-2 @ win11 either, so I set this to resolved.