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.

here's an example of no prompting at all using --pinentry-mode=loopback:

master is development and you can't expect that it always build on all platforms.

Here is a patch against master which normalizes line-endings when verifying text signatures over binary literal data packets