I think you are correct.

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. 8And yest we should add projtecs (tags) for gpgmepp and gpgmeqt

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.

Fixed:

Thanks for the patch but I think it is better to fix this in yat2m. I created a new tag for bugs related to it.

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.

IIUC, it's GCC 8 which starts the support of __nonstring__ attribute.

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.

And, one more update, to fix win32 builds under --disable-npth. This is a roll-up patch that i think covers everything, you can disregard the earlier patches posted here.

Hm, we probably should avoid gpgv linking to npth as well, as that's also a sticking point in debian. This updated patch (also targeting the 2.4 branch) also has gpgv building against libcommon instead of libcommonpth, which appears to remove the dependency for me.

This patch avoids the unnecessary libassuan linkage by creating a set of stub functions to handle the keydb formats while avoiding potential callouts to keyboxd:

Well, I could not reproduce this at any time but tested decryption with long file paths to be sure nothing broke and it worked fine.

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.

1.53 has been released this morning.

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.

Okay, thanks, I may join it later.

I did not run the full tests becaue those would take some hours but one test case using the genhashdata tool from the libgcrypt test suite gives the correct value (see genhashdata.c source)

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.