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.

t-stringhelp change was pushed by rG8a95e963d53a: common: Fix the test of t-stringhelp.
For int-truncation, I pushed the change rGbcd87ea2b2da: misc: Validate the value on the use of strtol.

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.

I can confirm that the patch fixes the issue. Thanks!

I am currently working on backup/restore of Kyber keys. The error message will go away.

There are a lot of other ways to confuse the user. We can't fix them all because the whole purpose of a cleartext signature is to make it easy to use in legacy environments like an BBS. Modern systems use MIME to handle this in a more stringent specified way. For any use it is stongly suggested to check the actual signed data which is avaialable with the --output options. At least a sanitizing viewer should be used which filters out all escape characters (something like cat -v |less).

We have seen wrong encodings quite often in the past and thus we won't apply the patch. After all the armor header is a different layer and could also be applied or removed by other software or tools. The integrity of an OpenPGP message does not depend on its concrete outer encoding.

For someone who considers the rejection is the requirement of the spec., here is a change:

Here is a revised patch (hopefully the last one):

This is caused by a bug in gpgsm. The card serial numbers are missing in the with-colon key listing.

That's my mistake with KEM API.

Alright, I change it from for notation data (and name).

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20��%20blub

with change:

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub

Since rfc2440 the PGP specs say:

Here is a patch (revised since the email of mine):

For t-stringhelp.c, here is a fix.

For

openpgp_oid_from_str has a wrong memory-safety assumption

For Integer Overflow in literals_seen, I think that the claim is wrong.
When literals_seen becomes two, GnuPG stops processing to return an error.
It's not possible for GnuPG to keep processing.

For Integer Truncation of Arguments report, since the int value is limited to one-octet value, we could add check for the length of input when we use strtol.

We have fixed it but the commit also states:

Added a compatibility flag in: rGad0c6c33c3d6: gpg: Do not use a default when asking for another output filename.

Fixed in rG115d138ba599: gpg: Fix possible memory corruption in the armor parser.

Fixed in rGdb9705ef594d: gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.