I once creates this task, which is probably a duplicate now: T7954: Kleopatra: Highlight focused cell in tables

In general, we don't show the key IDs. User ID + creation date will almost always uniquely identify all keys. (And only the fingerprint truly identifies a key anyway.)

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.

If Tobias remembered correctly, then https://dev.gnupg.org/T7334#193396 still needs to be implemented.

I've removed the sentence in the German de.po on master.

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.

There is no handling for installing a currently in use libwinpthread-1.dll and a few others. That will require a reboot anyway and thus it is only done for the more common cases like gpgol and gpgex. Workaround is to reboot and try again.

This happens occasionally and is not related to upgrading from 5.0.1 to 5.0.2. It can happen when installing any 5.0.x version (including the betas) over an installed 5.0.x.

The minimum fix avoids changes needed, thus, a bit confusing as a whole.
Here are better changes:

Minimum fix is:

Well, I don't think we'll add platform-specific X11 code to pinentry-qt just to check for an invalid DISPLAY. We are using Qt so that we don't have to deal with platform-specific stuff. I have no intention to look into this and, given Wayland, investing any more time in X11 feels wasted. We might accept a patch that can be used by all GUI pinentries to check for a usable DISPLAY.

"ikloecker (Ingo Klöcker)" wrote:

ikloecker added a comment.

How is "invalid DISPLAY" defined? `DISPLAY=invalid`? Anything that's not `DISPLAY=:<some number>`? Why do screen and tmux have to use an extra-wurst?

[...]

@werner I can confirm that we've tested the patch and it seems to fix the issue in our setup.

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.