The technical background is that opening the certificate details triggers an update of the certificate and this triggers an update of the drop-down. The drop-down should still keep the currently selected certificate even if it is not offered by default.

This is related to T6072: Kleopatra: Display "gpgconf -X"

The fix should probably be backported to gnupg 2.2 and 2.4.

The only thing that's a bit ugly is that there's no checkbox in front of "Encrypt for others" because it's mostly superfluous/redundant to the presence or absence of "other" certificates.

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.

I played a bit with the right pane to make it less wide. Here is how it looks (still WIP)

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

I'd have no objections against making it less prominent.
Instead of the "Protocol" label we could then maybe add a tooltip/info to the buttons with something like "the protocol to be used".
I know, tooltips are not popular with you ;-)

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 T5957#192566, @CarlSchwan wrote:

Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???

Agree

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

Good catch, @ikloecker !
I located the bug in GnuPG, and the fix is: rG71840b57f486: common: Fix a race condition in creating socketdir.

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.

Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???