Parts of the changes made for T7183: Kleopatra: Reduce certificates offered in Sign/Enyrypt dialog have been reverted. The drop downs for selecting the signing key and the "encrypt to self" key now offer the primary user IDs of usable keys again (instead of all user IDs of usable keys) and there's no button to open a certificate selection dialog anymore.

I looked at it but we probably need to rework/update the entire libtool stuff which has a high regression risk. Thus I give this bug a low priority because it is not a functional bug.

Just to be clear: You originally installed it as a portable applications and then you also installed a new version in the standard way?

I started Process Monitor only after Kleopatra hang so that I cannot find out which process started gpg-connect-agent.

Can you figure out who started gpg-connect-agent? Note that it is also used by gpgconf to reload, kill, or launch daemons.

And mind that the wording "This certificate is revoked" is wrong in any case, only the user ID is revoked, not the public key.

I stumbled into this problems myself yesterday. Time for a new release.

Log files for above deadlock

I just had another hang.

Once again, thank you for your reactivity @gniibe !

My test coverage was not good (even if I daily use Curve25519 on Gnuk Token).
Your analysis is correct.

Thanks for elaborating and the reference to rfc2440 - I now understand where that stray mail (between [RFC2822] and name-addr) in rfc4880 comes from...
Anyway, I'll treat it as if it says RFC 2822 mailbox and will treat angle brackets with bare addresses as optional.

In Kleopatra we explicitly trigger a re-reading of the smart card after each operation involving a smart card to ensure that Kleopatra doesn't show wrong information. There's so much that can go wrong with physical smart cards that this is the only way to make sure you don't tell the user lies. I think gpg --edit-card also re-reads the smart card after each operation.

There is no bug in the contexts and there's nothing to document anywhere. If anything then it's a bug in gpg's generate command or a more general issue (in gpg-agent) with keeping track of the storage location of private keys as I have already explained in T7620#200613. I'm removing the gpgme tag because there's nothing wrong in gpgme and there's nothing we can do in gpgme. It needs to be addressed in gnupg.