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.

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

Here is an attempt to fix the client side:

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

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

with Gpg4win-5.0.0-beta479 the listing after creating the new key with ADSK looks ok now:

Looks good to me on gpg4win-5.0.0-beta479 @ win11.
I can't reproduce ebo's nor pl13's issue.

This has likely a similar cause as T1794

I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:

• Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)

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).

This relates to T7917: Check for revocation of the ADSK's original subkey

The expected behavior is that only "Ted" (the key from where the ADSK originates) is listed, regardless of ADSKs, on every listing.
Because for regular keys there can only ever be one, "gpg -k" shows always only one key.
Subkeys which are ADSKs shall therefore never be listed with this command.

Tested with Gpg4win-5.0.0-beta446, identically to the procedure from the description:

It is not an ADSK issue. The problem is that the new subkey has not been entered into the fingerprint table and can thus not be found.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

Lucas Mülling commented yesterday on gnupg-devel:

We suggest the use of the keyboxd for a reason. The use of multiple keyrings has always been a problem and has been kept on demand from a couple of people. Eventually things change and for a new installation the use of the keyboxd is the suggested way to run GnuPG. Support for pubring.gpg and even pubring.kbx may eventually be removed - not now or in the next year but it may happen. You have been warned ;-)

FWIW: It does works when using GNUPGHOME instead.

similarly, gpgconf --homedir /tmp/gg --kill all does not terminate keyboxd, despite the fact that gpgconf(1) says:

Closed after the release of 2.5.4