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:

Still good for experiments.

That RFC is Experimental anyway

Still good for experiments.

Here is my proposal:

git checkout gnupg-2.5.14, reverted the commits 46f4cb66125ee34e87e592cc02d38daead3427af and 0cc7759ed5a3890b4e28563a6b5e97f3aa551530, recompiled, and the error message gpg: keydb_search_first failed: SQL error no longer appeared. Also, in /root/.gnupg/public-keys.d/, the two files pubring.db.lock and .#lk0x0000... are present.

Note: Backup/Restore secret kyber keys looks good to me on gpg4win-5.0.0-beta413 @ win11 now.

Let me explain about the change rG57affc4e98ab.

Additionally, in the /root/.gnupg/public-keys.d/ directory, the two files .#lk0x00007fdcb40043b0.b02bef684bbe.5108 and pubring.db.lock are missing.

gpg was compiled with the latest version of SQLite3 at the time as its own private library, without linking against the system's libsqlite3.so.

Can you please schek which Sqlite version you have installed? I have not seen this on my system.

keyboxd (GnuPG) 2.5.13

gpg -K
cat keyboxd.log

listening on socket '/root/.gnupg/S.keyboxd'
keyboxd (GnuPG) 2.5.13 started
handler 0x7f2eba314640 for fd 9 started
connection from process 4361 (0:0)
(SQL: PRAGMA foreign_keys = ON)
(SQL: CREATE TABLE IF NOT EXISTS config (name  TEXT NOT NULL UNIQUE,value TEXT NOT NULL ))
database version: 1
database created: 2025-11-20 06:11:12
(SQL: CREATE TABLE IF NOT EXISTS pubkey (ubid     BLOB NOT NULL PRIMARY KEY,type  INTEGER NOT NULL,ephemeral INTEGER NOT NULL DEFAULT 0,revoked INTEGER NOT NULL DEFAULT 0,keyblob BLOB NOT NULL))
(SQL: CREATE TABLE IF NOT EXISTS fingerprint (fpr  BLOB NOT NULL PRIMARY KEY,kid  BLOB NOT NULL,keygrip BLOB NOT NULL,subkey INTEGER NOT NULL,ubid BLOB NOT NULL REFERENCES pubkey))
(SQL: CREATE INDEX IF NOT EXISTS fingerprintidx0 on fingerprint (ubid))
(SQL: CREATE INDEX IF NOT EXISTS fingerprintidx1 on fingerprint (fpr))
(SQL: CREATE INDEX IF NOT EXISTS fingerprintidx2 on fingerprint (keygrip))
(SQL: CREATE TABLE IF NOT EXISTS userid (uid  TEXT NOT NULL,addrspec TEXT,type  INTEGER NOT NULL,uidno INTEGER NOT NULL,ubid BLOB NOT NULL REFERENCES pubkey))
(SQL: CREATE INDEX IF NOT EXISTS userididx0 on userid (ubid))
(SQL: CREATE INDEX IF NOT EXISTS userididx1 on userid (uid))
(SQL: CREATE INDEX IF NOT EXISTS userididx3 on userid (addrspec))
(SQL: CREATE TABLE IF NOT EXISTS issuer (sn TEXT NOT NULL,dn TEXT NOT NULL,ubid BLOB NOT NULL REFERENCES pubkey))
(SQL: CREATE INDEX IF NOT EXISTS issueridx1 on issuer (dn))
database '/root/.gnupg/public-keys.d/pubring.db' created
(SQL: SELECT ubid, type, ephemeral, revoked, keyblob FROM pubkey as p WHERE p.type = 1 ORDER by ubid)
(SQL: SELECT ubid, type, ephemeral, revoked, keyblob FROM pubkey as p WHERE p.type = 1 ORDER by ubid)
command 'NEXT' failed: Not found
handler 0x7f2eba314640 for fd 9 terminated

Interesting. What SQlite version are you using? To see the exact reason and you have a copy of the old pubring.db, please add

Applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

I applied a change with GPGRT_ATTR_NONSTRING to master, since 2.6 branch now requires newere gpgrt.
Fix is rGcad79e542d85: agent,common,dirmngr,tests: Silence warnings of a compiler.

The problem is that a user may unintentionally use the suggested filename without checking that it does not harm to write to this file. It is better not to present a default name at all.

The revision was actually applied (rG0947a20c28cf: gpgsm: Fix output of card serial number in colon listing.), but Phabricator doesn't allow me to set it as applied because not all reviewers have approved it.

Fix applied. Thanks.

This is not a composite key specific thing despite that this is an extra challenge. The creation date is used to reconstruct a key if the public key has been lost and only the fingerprint is still available. A solution might be to test the all combinations of stored creation dates to match the fingerprint.