Applied to master.

I created a branch https://dev.gnupg.org/source/gnupg/history/gniibe%252Ft8048 and pushed all changes (including keyboxd-patch-2026-04-23).

Enhance keyboxd to have new command for what keybox_set_flags does.

Still does not work on vsd-3.3.7-beta90.9 @ win10. Essentially the same behavior as before:

I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

Here is an attempt to fix the client side:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

I looked at sm/keydb.c:keydb_set_ephemeral function. It says:

Implemented and backported for VSD 3.4

The "ca" root cert is not on the ldap, if that matters

In T8048#211860, @ikloecker wrote:

some other certificates, but I guess those are from other tests

It also happens on CLI:

With Gpg4win 5.0.0 the LISTKEYS after the server lookup lists the (ephemeral?) ca@gnupg.test certificate and (!) the bob@gnupg.test certificate (and some other certificates, but I guess those are from other tests).

1. VSD 3.3.4

1. Gpg4win 5.0.0

• gpg4win 5.0.0 @ win11

gpgme logs (also of vsd-3.3.4) will be useful.

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

Note: This does not happen on vsd-3.3.4

The gpgme logs show that the information for revoked keys should be there. We just need to check for it (and somehow visualize it).

pub:o:3072:1:3DA05D6B0A5998AF:1768822823:1863514800::::::::
fpr:::::::::C70F6D8F32DFE96F5C47C40B3DA05D6B0A5998AF:
uid:o::::::::search (valid) <search@gnupg.test>\r:

gpgme.log (vsd 3.3.4):

Another possibility would be to just add a revoked column (expiration date is already shown) to keep closer to the ldap schema.

The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

Looks good to me on gpg4win-5.0.0-beta479 @ win11.

@timegrid I would not tag this ticket with LDAP, as it is not LDAP specific