the included tools are intended to bootstrap things and are not optimized in any way. We don't run large data test either. Someone will look into it, thoigh. A better way is to use

Pushed all changes to master.

Sorry, I sometimes forget to push the tags. If you have access to a jabber/xmpp client you may join the gnupg-devel@chat-gnupg.org muti-user-chat and ping us there.

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:

I applied some to master (generic improvement parts).

Is not a GpgOL bug.
Full functionality will be possible with GpgOL/WEB.

I think that this may be the last update.
Don't use mpi_powm to avoid normalizing (and to be faster).

IIUC, the address is stored with lowercase, but searching is done not converting lowercase.

Here is another update (replacing ecc-no-normalize-2025-03-13.patch).
Further, ec_addm is modified to be less leaky.

FWIW: It does works when using GNUPGHOME instead.

There are three (or more) remaining things:
(1) ec_addm can be improved by adding U and V with mpih_add_lli , subtracting P with mpih_sub_n, and adding back P with mpih_add_n_cond
(2) Places with mpi_const for the argument when calling ec_mulm, ec_add or ec_subm should be fixed (it may modify the const MPI)
(3) make sure mpi_resize within ec_addm, ec_mulm, or ec_subm if needed

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:

Done

Re-opening because I think rGaa36f6ae8bae needs to be backported to GnuPG 2.4 (see T7568). The fix for T7309 which introduced the regression has been backported to GnuPG 2.4.

Duplicate of T7457. Sorry for the noise.

I've offered https://github.com/bestpractical/gnupg-interface/pull/16 to GnuPG::Interface, and am testing it out in debian unstable.

I'll work on making a patch to offer a flexible test suite.

Alternately, i suppose we could ask GnuPG::Interface to drop the variant parts of that test entirely. @werner, If you have a preference for what they test, it would be good to know. I suspect your opinion would carry weight with the maintainer there.

Well, we also have the gpgme test suite which tests a couple of other things and for obvious reasons we need to keep this stable. Granted, sometimes we had to change the gpgme test suite as well. My personal preference would be your second choice.

Thanks for the fix for the double-free on --no-sig-cache, that appears to be an issue on all released gpg versions, as i can crash them directly when i --no-sig-cache.

I think it's not exposed in the user interface. You can manually set it by adding