I'm wondering if/how we can get rid of the checkbox before "Encrypt for me". Do we even need to distinguish between "for me" and "for others"? It has always felt wrong to me that we have completely different UI for selecting my single (!) key and multiple other keys. What if I want to encrypt to two keys of me? Makes no sense to enter my second key under "Encrypt for others". What if somebody always wants to encrypt everything to two of their keys, e.g. because they use different keys on different devices? But that also applies to the file encryption dialog so maybe that's a different discussion.

In T5957#192598, @ebo wrote:

But what I don't understand is: why do we need the buttons? For other encryption actions in Kleo you can choose from all available keys, regardless of their protocol.

I confirm the fix. Using gnupg master the unit test ran 544 times without any failures or suspiciously long run time.

My last comment makes things look more complicated than they are.

Okay, then we keep the protocol radio buttons for now, but I guess there's no reason not to make it less prominent. I would even argue that the label "Protocol:" isn't really helpful and could be removed.

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