The first call of get_key receives the following key listing from gpg:

2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: sec:-:256:19:C4A24EB0B5F2E025:1746474606:::u:::s
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: cESCA:::D2760001240100000006180489130000::brainp
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: oolP256r1:23::0:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::DEC0948C398A6E7B50746EC6C4A24EB0B5F2
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E025:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::06BDACFBDEDBC5783A75AE5E7251FA3369C4
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 0FF4:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: uid:-::::1746474606::2222D8E2F373B9BDEE0DEA2A20A
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 9402214E9F984::Eric <eric@bktus.com>::::::::::0:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: <LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:19:EAFC5EA29B758B22:1746474606::::::a:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::D2760001240100000006180489130000::brainpoolP25
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::1AD596DDEC9B8CF3C1AC6C41EAFC5EA29B75
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 8B22:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::52F0797C0B0439BBD718E2534D46656A6C45
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6A78:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:18:A874804DB497B91C:1746474606::::::e:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::#::brainpoolP256r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::33B273C7BD46E4EB63DD6874A874804DB497
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: B91C:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::34A1F8D9B2AA0CF07C2E042D70E10F9D4EBE
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E734:<LF>

Note the line

ssb:-:256:18:A874804DB497B91C:1746474606::::::e:::#::brainpoolP256r1:23:<LF>

where the # marks the subkey as stub.

Right now we have

Interesting, that sounds like a portable method. I am not very familiar with GPG internals, but to me that sounds like quite a bit of work. Unless there is another benefit to doing so, I don't think it is worth it just to print signal names.

I have now identified the exact conditions and a reproducible path for the issue I previously reported. I will also attach the relevant gpgme.log.

I doubt that this is a gpgme problem. With a gpgme log we will be able see the exact commands send to gpg and replicate this on the command line.

And the US administration might even change the definition of a year to, say, 100 months so that potus can rightfully keep his promise that there won't be more election in the foreseeable future ;-)

By the way, "years" is also "incorrect" once in ~4 years because it uses n*365 days. Werner's advice still applies. Enter an ISO date if you want an exact date. Or use a UI tool like Kleopatra.

The main problem here was that this all is not async-safe and thus I once implemented only the standard cases I could test easily.

The logs of gpgme would be helpful, i.e. run your test program with GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log to create a log file with gpgme's logs.

For the records:

A bug tracker shall never be used for discussion because the audience is not as expected. Only very few people follow a certain bug but several hundreds are following discussion on gnupg-devel@. That is basic hacker knowledge.

I am surprised that you don't want to use the issue tracker for issues.
GnuPG's trust calculations are quite clearly broken, by any metric. There's nothing to discuss here.

Heiko, I told you already in T7106 that it is not a good idea to re-open a ticket. If you really want to discuss stuff, take that to a mailing list.

I see two interesting angles from which to think about this Web of Trust calculation:

Yes, this is related to T7547. With my last fix for that I overlooked that we use PUBKEY_USAGE_CERT to internally request the primary key but that one is not set because in general USAGE_SIG means the same (except for some case in PGP7 mode).

> I'm not sure i understand why "the latest" should be preferred.

A bit more experimentation shows the same behavior, even if Alice's tsig of Bill is full, not marginal, and even if all signatures are made in the same second, which is the finest resolution that OpenPGP objects can report.

Interesting analysis, thanks for the sleuthing! I'm not sure i understand why "the latest" should be preferred. For example, in the graph made in this example, which part of the graph is the "latest"? Since the path from Alice to Carol is two hops long at least, it's conceivable that one path (A→Bob→C) has both "the latest" tsig *and* "the earliest" tsig, if the other path (A→Bill→C) happens to have been made between the other two tsigs.

I also spend some time with this and the problem is described by this comment in trustdb.c:

No, it is not a bug and I beg you not to change the status again. Don't start the same trouble here as some of you guys did with the IETF WG!

Err, I don't see why I would "need to test" anything further.

This is just one build of PGP and you would need to test all versions on Windows, macOS and Unix. You also need to test against all versions of GnuPG since 1998 (when we started with interop tests). We won't change this in GnuPG and risk regression. If you have a problem with that go and add a fix to your tool - name it bug compatibility or whatever. And please do not re-open this bug.

In T7106#185462, @werner wrote:

This has been implemented and tested to be compatible with PGP - a looong time ago. iirc this was discussed around 1999 but might be only by private mail between the PGP hackers and me. Thus any change now might break PGP - which is still widely used (although mostly for encryption).

The report is correct but it does not make sense to fix it. If you want to use a concrete expiration date just enter the IS date at the prompt; use ? at the prompt for a short description.

This is really a minor thing and and it is actually true if you also sign something.

doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

Good morning,
I stumbled upon this when digging through old Debian bug reports against 1.4 and checking whether they still applied to 2.4. This one really still applies.

POSIX specifies and requires grep -E, but only mentions egrep as old.

Removing egrep from a Unix system will break all kind of stuff. I am not even sure whether old Unices support grep -E.

There is no well defined pripority for the CRL DPs. The code enumarates the DP and tries one after the other until it founds one. If you use --ignore-http_dp http DPs are skipped and with --ignore-ldap-dp LDAP DPs are ignored.

Fix pushed by: rG1ed8b0e7b403: dirmngr: Fix libdns with 127.0.0.1.

For Linux kernel, once, it was proposed:
https://patchwork.ozlabs.org/project/netdev/patch/1490748756.24891.27.camel@edumazet-glaptop3.roam.corp.google.com/

Another problem with same cause (possibly) is reported: https://lists.gnupg.org/pipermail/gnupg-devel/2025-April/035845.html

this marked as fixed in 2.4.7. However afaict only one of the two patches made it to STABLE-BRANCH-2-4, b1857a2836c9a91ef4e359ef7ba949b54c77219d did not.

OK. Relying on SQLite semantics for COLLATE NOCASE would not be good.
Exactly same existing semantics (only care about ASCII uppercase characters) is good.

I noticed that the signing key B0D589D46708EC99 is a certify-only key. That signatures made with this key are dropped could be another regression of the fix for dkj's DoS bug.

Taking a bigger sample of keys from the same domain and doing the same testing shows that the signature by B0D589D46708EC99 is removed on all keys.

You mean this would be better becuase it is not clear how we handle X.509 addrsppec (see override_mbox arg of store_into_userid)? I guess COLLATE NOCASE does it the standard way by folding all uppercase characters and not just the ASCII characters as we do in GnuPG. This would be a problem.

Indeed, GnuPG's IPC uses TCP connections from 127.0.0.1 to 127.0.0.1 taking the destination port (and a cookie) from a file. We can't change that easily to the new Unix socket implementation Windows recently introduced. I hope there is a way to exclude localhost->localhost from congestion control.

I changed my mind. SQLite specific patch might be better:

diff --git a/kbx/backend-sqlite.c b/kbx/backend-sqlite.c
index 4c67c3ef7..1db2f2c8d 100644
--- a/kbx/backend-sqlite.c
+++ b/kbx/backend-sqlite.c
@@ -154,7 +154,7 @@ static struct
      /* The full user id - for X.509 the Subject or altSubject.  */
      "uid  TEXT NOT NULL,"
      /* The mail address if available or NULL.  */
-     "addrspec TEXT,"
+     "addrspec TEXT COLLATE NOCASE,"
      /* The type of the public key: 1 = openpgp, 2 = X.509.  */
      "type  INTEGER NOT NULL,"
      /* The order number of the user id within the keyblock or

I changed my mind. SQLite specific patch might be better:

diff --git a/kbx/backend-sqlite.c b/kbx/backend-sqlite.c
index 4c67c3ef7..1db2f2c8d 100644
--- a/kbx/backend-sqlite.c
+++ b/kbx/backend-sqlite.c
@@ -154,7 +154,7 @@ static struct
      /* The full user id - for X.509 the Subject or altSubject.  */
      "uid  TEXT NOT NULL,"
      /* The mail address if available or NULL.  */
-     "addrspec TEXT,"
+     "addrspec TEXT COLLATE NOCASE,"
      /* The type of the public key: 1 = openpgp, 2 = X.509.  */
      "type  INTEGER NOT NULL,"
      /* The order number of the user id within the keyblock or

Here is a possible change:

FWIW: It does works when using GNUPGHOME instead.

This has always been the case. git blame shows for check_signatures_trust:

This seems to be the case on 2.2.46 as well, fwiw. i don't think it's new in 2.4.7.

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

Hello Eva,

The beta145 Werner talks about can be found here: https://www.gpg4win.org/version5.html
It is from our master branch which is not de-vs capable at this time.

Hello Werner,
thank you for your support ...

Please test using the latest gpg4win installer (beta145).

The problem is that it may take really long to read the certificates form a card and some card applications even require to give a PIN for reading the certs. A background operation may thus surprisingly lock up the box

This was using GCC to build, but on AIX. I believe support for dollar signs in identifiers are platform specific.

GCC allows dollars in identifier, that's the reason why we haven't encountered this issue, I suppose.

Thank you for your report.

thanks for the fix in f29c8dba743eb7574399345ce341bbfb1f8f9bee !

rG25d48663f9 seems to fix this for me. However in my test cases I got a hang in dirmngr simply by running several gpgsm instances to get the details of an X.509 key. I had different logging options enabled, though.

I had this again yesterday. I don't think that scdaemon is involved. gpg-agent.log has this

2025-03-05 15:54:29 gpg-agent[1248] socket file removed - retrying binding
2025-03-05 15:54:29 gpg-agent[1248] Der Socket kann nicht an `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gebunden werden: Unknown error
2025-03-05 15:54:29 gpg-agent[1248] system error code: 0 (0x0)
2025-03-05 15:54:29 gpg-agent[1248] secmem usage: 0/32768 bytes in 0 blocks
2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding
2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent' gehört
2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding
2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.extra' gehört
2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding
2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.browser' gehört
2025-03-05 15:55:17 gpg-agent[2088] socket file removed - retrying binding
2025-03-05 15:55:17 gpg-agent[2088] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.gpg-agent.ssh' gehört
2025-03-05 15:55:17 gpg-agent[2088] gpg-agent (GnuPG) 2.5.5-beta11 started

and scdaemon logged

2025-03-05 15:55:19 scdaemon[4100] Es wird auf Socket `C:\\Users\\g10code\\AppData\\Local\\gnupg\\S.scdaemon' gehört
2025-03-05 15:55:19 scdaemon[4100] Handhabungsroutine für fd -1 gestartet
2025-03-05 15:55:19 scdaemon[4100] DBG: chan_0x00000000000002d0 -> OK GNU Privacy Guard's Smartcard server ready, process 4100

i.e. there wasn't any scdaemon running before the second gpg-agent started successfully.

Thanks for the report! That's indeed a regression introduced by the changes for T7527: Keyring/keybox denial of service. Commenting/Removing line https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$343 seems to fix the regression, but (very likely) this would reintroduce the issues reported in T7527: Keyring/keybox denial of service.

whether you use --pinentry-mode=loopback or --pinentry-mode=cancel or --pinentry-mode=error, if gpg-agent has cached the password already, the decryption will work; otherwise, it will fail with an error like that describe above.