I don't know what you understand as "does work". For single files two completely separate things are done:

1. A detached S/MIME signature for the unencrypted file is created.
2. The unencrypted file is S/MIME encrypted.

The easiest fix is to enable the "exclusive" mode that we use for the notepad (and the clipboard) also for the Sign/Encrypt Files/Folder dialog. This will disable mixing of OpenPGP and S/MIME recipients (which is anyway misleading because in case of encryption the result is two separate encrypted files with mutually exclusive recipients). Moreover, for S/MIME, it will disable "combined" sign and encrypt.

Note: I decided to add "detached" or "embedded" before "signature(s)" to give a hint where the signature(s) come from.

Fixed and backported for VSD 3.4.

It is more a regression (compared to older behavior that's still used for detached S/MIME signatures) that the full paths were shown. Therefore, I'll backport this for VSD 3.4 (as originally planned).

Fixed and backported for VSD 3.4.

This fix should be backported for VSD 3.4.

The "missing path" on verification of test.txt is caused by a bug in the code: T8337: Kleopatra: Verifying detached OpenPGP signatures uses different code paths.

In T8324#220048, @timegrid wrote:

What would be the issue with first encrypting the tarball and then sign that resulting tar.gz.p7m to create a tar.gz.p7m.p7s?

Could we make a detached signature in this cases, too, like for the single files?

No. The detached signature would sign an ephemeral archive. The signature could never be verified because the data that was signed doesn't exist as a file.

Fixed. And backported for VSD 3.4.

It looks like the audit log is requested with the command GETAUDITLOG --data --html which prints the details (including information about all recipients) as HTML. So, obviously, gpgsm has the necessary information. It just needs to emit ENC_TO status lines for the additional recipients.

The root cause is that gpgsm outputs a TRUST_UNDEFINED status line for the encryption certificate. The data is not signed. If gpgme sees a TRUST_* status line without preceding *SIG (GOODSIG, EXPSIG, ...) status then gpgme sets the error GPG_ERR_INV_ENGINE:

2026-07-07 15:51:24 gpgme[6944.280]       verify.c:1001: returning error: Invalid crypto engine\n

As you can see in the output of gpgsm it only prints ENC_TO status lines until the decryption succeeded. Hence, neither gpgme nor Kleopatra can know that there are more recipients. Interestingly, the audit log seems to have more information. I have no idea what black magic the audit log uses.

Should now look like vsd-3.3.7 again.

Please retest with the next VSD 3.4 build.

I'll apply different fixes to avoid the regression T8322: Kleopatra: Low contrast boders in high contrast mode.

Implemented and backported for VSD 3.4.

I cannot reproduce this with GnuPG 2.2.45-beta27 or GnuPG 2.5.21-beta1 on Linux. Neither on CLI nor with Kleopatra.

Note: In Gpg4win 5.0 (and later) the problem doesn't occur because the problematic code was changed about two years ago. I have backported the relevant changes that fix the problem.

I can reproduce some weirdness. Some filters can be selected (e.g. Certified, Expired, ...), but when I try to select Disabled or "Fully Qualified" then the filter switches to All.

In T6702#219707, @timegrid wrote:

• On gpg4win, the button is not red - that's ok?

The root cause is that we now use the Fusion style for high contrast because the Windows style had more severe issues with high contrast (see T7585: Kleopatra: wrong color for some button texts in "high contrast white" setting ).

This looks like an error in the backend or in gpgme. If the backend/gpgme reports that the operation was canceled by the user then we usually don't show any message. In particular, we never show an error message if no error has been reported.

The usage column now shows the usage of the certificate if there is a certificate for the card slot. Otherwise, the "default" usage (as reported by scdaemon) is shown.

The idea to fix this is to use the common capabilities of card slot and key (if a key exists for the slot).

Fixed and backported for VSD 3.4

I cannot reproduce this problem with a locally-built AppImage when I run kde-open from the AppImage's shell. kde-open <some PDF> opens the PDF Okular (I had to fix a problem with the loading of the part plugin, but you should have at least seen the error message that the part plugin couldn't be loaded). kde-open <some JPEG> opens the JPEG in Gwenview.

Okay. So we should add the kde-cli-tools package to the AppImage.

Did you compare ownertrust files exported after the problem occurs with files exported after the problem was "fixed"? A possible explanation would be that the trustdb (re-)calculation aborts in the middle and overwrites the previous correct result with a partial result. (I have no idea how the trustdb (re-)calculation works. Is it "throw everything away and start from scratch"?)

The same crash will likely occur if the user tries to open an attachment shown in the mail viewer included in Kleopatra. Hence, I think we have to include kde-open in the AppImage. On the other hand, I'm wondering if kde-open is even used with other Linux desktops, but at least gnome-open (or whatever it's called) won't depend on Qt and therefore will hopefully avoid a library version mismatch.