In the second case, gpg emits a FAILURE gpg-exit 33554433 status at the end. I think this makes gpgme consider the operation failed. I think this is a bug in gpg because gpg does not emit a FAILURE status if a wrong symmetric passphrase is entered.

In the first case, gpg emits a CANCELED_BY_USER status. This makes gpgme abort the operation. We may have to wait/watch for BEGIN_DECRYPTION / END_DECRYPTION.

When looking at Carl's first MR I had a few ideas/thoughts:

• Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???
• I wondering whether we should move the checkboxes to the group box titles and get rid of the group boxes and instead use KSeparators to separate the different sections, i.e.

[ ] Prove authenticity (sign)
Sign as:
------------------------------
[ ] Encrypt
Encrypt for me:
Encrypt for others:
------------------------------
[ ] Encrypt with password
Anyone ...
------------------------------
[Sign and Encrypt]

I found one reason for the intermittently failing concurrent initial keylisting. gpgsm sometimes uses the wrong socket file to (try to) connect to gpg-agent.

I don't think gpg/gpgsm tell gpgme "the keyblock used for decryption". They simply log all public keys used for encryption via STATUS_ENC_TO in the order the packets appear in the encrypted file.

In T7334#192524, @werner wrote:

For a subkey the user id of its primary should always been show.

In case of an unknown encryption subkey we could check if it's the ADSK of a known recipient and then display something like

Unknown ADSK for "Some key with ADSK <with-adsk@example.net>"

instead of

unknown recipient

I can reproduce this with gnupg 2.2.45-beta27 (STABLE-BRANCH-2-2 69a8aefa) on openSUSE Tumbleweed.

Is this R-flag part of the status logging, i.e. do we need to add handling for this in gpgme?

I have reproduced this with libkleo from our gpg4win/24.05 branch and with gpg (GnuPG) 2.4.6-beta102 (HEAD of STABLE-BRANCH-2-4) and current master of gpgme and all GnuPG libraries. It took just 8 runs until a unittest failed.

gpgme logs for a failed test where the keylisting with gpgsm failed

If the keylisting (of OpenPGP and S/MIME certificates; technically, that's two independent keylistings) fails without giving any results then it makes sense to show a error message instead of the welcome page.

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

Yes, the fix is included in the Gpg4win 4.3.1.

Backported for gpg4win 4.x

Andre, didn't we conclude that there's nothing worth migrating except the groups configuration (which is migrated)?

Yes, gpg logs "invalid ADSK ... specified", but it doesn't emit a status error. This needs to be changed in gpg.

I knew that we'd need something like D604 when I saw rM409e31458227, but then I forgot about it. :/

Looks good! Thanks!

Given that this only happens if keyboxd is used I doubt that this is relevant for VSD 3.3.

This happens only if keyboxd is used because then Kleopatra doesn't notice any changes in GNUPGHOME and therefore doesn't run a key listing.

gpgme should handle lists correctly. In Kleopatra those options are not shown in the configuration dialog because they are GC_LEVEL_INVISIBLE, i.e. Kleopatra can read them programmatically but they are not shown to the user.

Translations of the tooltips (and names) of the filters defined in the libkleopatrarc*.desktop files have to be merged/copied manually for VSD 3.3. With rLIBKLEO2349aea7f7f3ad7d785cef644befd4bdbc9d0962 I have updated the translations to the state in master. Currently, none of the tooltips have a German translation.

Backported for VSD 3.3

Backported for VSD 3.3

Backported for VSD 3.3 (backported manually because in master the code has been moved from kleopatra to libkleo)

Backported for VSD 3.3

Backported to VSD 3.3

Re-adding vsd33 tag. I added the relevant commit(s) to the task.

Backported for VSD 3.3 together with changes made for T6666.

The tool tips were added for T6666 which is not flagged for VSD 3.3. T7300 was never relevant for VSD 3.3 since there are no filter tool tips in VSD 3.3 that would need to be changed to sentence case. -> I remove the vsd33 tag.

I don't know what to backport because neither this ticket nor T7300 mention any commits.

Fixed.

I expect that the user can change the expiry date to 01.10.2024 but nothing else.

In T6882#191854, @werner wrote:

While testing this I noticed that only the last adsk or trusted key is listed. Thus several assurances of this options are not properly represented. See T7313

This has been addressed with T6878: Kleopatra: Subkey expiry date improvements by showing the expiration date of the primary key if the subkey doesn't have an expiration date.

Yes, for historical reasons (i.e. we haven't changed this) the width of the name and email columns always defaults to 260.

V5 keys should now work as good as V4 keys in Kleopatra. For testing create a "Curve 448" key and then try a few things. Everything should just work because it works for gpg. Kleopatra doesn't really do anything special for V5 keys.

Done. I don't think this needs to be tested extensively because it's just some UI texts that now show the Key ID (with 16 hex chars) instead of the short Key ID (8 hex chars). And for files including key material we also use the Key ID (of primary key and/or subkey) now for the filenames, e.g. when exporting a public/secret key/subkey.