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

In T8215#217199, @uwi wrote:

Anyway after reboot I could complete the update. The only think I had noticed was that Kleopatra's hair is blue now (it had been red in the past) ;-)

By the way, your screenshot shows the wrong folder. That's why you didn't see the file that the error message mentions.

Note that the error message may occur a last time when 5.0.2 (or earlier) is updated to a newer version because the uninstaller of 5.0.2 cannot be fixed retroactively.

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.)

Citing the API documentation of CreateNamedPipe (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea):

One of the following remote-client modes can be specified. Different instances of the same pipe can specify different remote-client modes.

PIPE_REJECT_REMOTE_CLIENTS Connections from remote clients are automatically rejected.
0x00000008

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.

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.

The attack works like this: An unprivileged user starts an application which creates a window like the one Kleopatra looks for. Then the normal user (or an admin) starts Kleopatra. Kleopatra finds the existing window (it looks for any window with the right name) and grants the unprivileged process full access to the Kleopatra process. Now the unprivileged process can do anything the Kleopatra process can do.

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.

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.)

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?

Apparently, DISPLAY is hostname:displaynumber.screennumber where hostname and .screennumber are optional and where hostname is a hostname or maybe host/unix. Does hostname include IPv6 address literals? Anyway, I guess the only sensible heuristic is to consider any DISPLAY value that contains : as valid.

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?

As noted by @ametzler1 pinentry-qt has such a fallback. Of course, we can try to improve the heuristics pinentry-qt uses.