Fixed. This only occurred on Linux, i.e. it should be tested with the AppImage.

Fixed. Requires (a release? and) an update of gpgex in all gpg4win branches that use gpgex-1.1.0.

I think I see the problem. Actually, gpgex looks relative to the install directory of Gpg4win or GnuPG-[VS-]Desktop while the above listed relative paths assume the bin (or bin_64) folder.

"Invalid argument" could mean that gpgex doesn't find gpgconf (which it needs to ask for the socket dir). gpgex looks in the following folders (relative to gpgex.dll):

• "../GnuPG/bin/gpgconf.exe", /* GnuPG-[VS-]Desktop */
• "../../GnuPG/bin/gpgconf.exe", /* Gpg4win. */
• "../bin/gpgconf.exe", /* Legacy */

Was Kleopatra already running? If not, does it work if Kleopatra is already running?

Debug logs might help. A debug file path can be specified with the registry value "GpgEX Debug File" in the HKLM\Software\Gpg4win key.

Also setting fixed for VSD 3.4 assuming that gpg4win-tools will be updated for VSD 3.4. (There are no branches in gpg4win-tools.)

Immutability should now be respected for all settings on the GpgOL config page. Additionally, the "autoencryptUntrusted" option was sometimes enabled even if "autoresolved" was unchecked.

Because the main reason for writing this ticket turned out to be wrong I'll prioritize this as wishlist. Ideally, gpgtar learns to do S/MIME encryption (I thought there was a ticket, but I didn't find one) additionally to OpenPGP encryption.

Further tests show that this has nothing to do with tar vs. gpgtar. It turns out that the "Input/output error" does *not* occur if the archive file already exists and Kleopatra asks if the file should be overwritten. Further tests show that this seems to be a timing issue.

This seems to happen only on Linux where tar is used for creating the archive. If I change pack-command-cms (in libkleopatrarc) to 0|gpgtar --utf8-strings --cms --skip-crypto --output - --encrypt -T- --null -- (which is basically the same as used on Windows) then the problem doesn't occur. Apparently, tar behaves differently than gpgtar.

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?