Fixed in gpg4win-5.0.0-beta476

This has likely a similar cause as T1794

Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:

Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).

Except for GpgEX which I am currently working on.

Indeed. We would need to add different entries to the context menu for each installation. Given that GpgEX needs to be replaced anyway and we will drop the need for a UI server socket (which is anyway only a trigger and no full communication).

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

That RFC is Experimental anyway

Still good for experiments.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.

Good catch. My guess is that get_uid_for_sender returns the last matching UID without checking for revocations. The matching was done on the mailbox part only. For reference:

Yubikeys allow that. See my mail to the mailing list.

Do you mean one of the user-ids has been revoked or the one matching the mail sender?

That is a feature not a bug. Make also sense if your threat model is store-trafic-no-decrypt-later. If you can get the key you will also be abale to get the cleartext. Any nobody can remember a passphrase on par with the claimed Kyber security level.