From jussi.kivilinna at iki.fi Mon Feb 2 19:21:56 2026 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Mon, 2 Feb 2026 20:21:56 +0200 Subject: [PATCH] configure.ac: fix HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS on x32 targets Message-ID: <20260202182156.2115138-1-jussi.kivilinna@iki.fi> * configure.ac (gcry_cv_compiler_defines__x86_64__): New. (HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS): Enable if __x86_64__ macro is defined by compiler and size of long is 4 (x32) or 8 (amd64). -- Signed-off-by: Jussi Kivilinna --- configure.ac | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index be6b29b4..d94319cc 100644 --- a/configure.ac +++ b/configure.ac @@ -1829,6 +1829,25 @@ if test $amd64_as_feature_detection = yes; then fi +# +# Check whether compiler defines __x86_64__ macro (amd64 or x32) +# +AC_CACHE_CHECK([whether compiler defines __x86_64__ macro], + [gcry_cv_compiler_defines__x86_64__], + [if test "$mpi_cpu_arch" != "x86" || + test "$try_asm_modules" != "yes" ; then + gcry_cv_compiler_defines__x86_64__="n/a" + else + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [[ + #ifndef __x86_64__ + # error "Architecture is not x86_64" + #endif + ]])], + [gcry_cv_compiler_defines__x86_64__=yes], + [gcry_cv_compiler_defines__x86_64__=no]) + fi]) + + # # Check whether GCC assembler supports features needed for our i386/amd64 # implementations @@ -1859,7 +1878,9 @@ if test $amd64_as_feature_detection = yes; then [gcry_cv_gcc_x86_platform_as_ok=yes]) fi]) if test "$gcry_cv_gcc_x86_platform_as_ok" = "yes" && - test "$ac_cv_sizeof_unsigned_long" = "8"; then + test "$gcry_cv_compiler_defines__x86_64__" = "yes" && + (test "$ac_cv_sizeof_unsigned_long" = "4" || + test "$ac_cv_sizeof_unsigned_long" = "8"); then AC_DEFINE(HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS,1, [Defined if underlying assembler is compatible with amd64 assembly implementations]) fi -- 2.51.0 From zach.fogg at gmail.com Thu Feb 5 01:23:01 2026 From: zach.fogg at gmail.com (Zachary Fogg) Date: Wed, 4 Feb 2026 19:23:01 -0500 Subject: EdDSA Verification Bug - Clarification on Format 2 Verification Failure In-Reply-To: <87pl7b7zxh.fsf@jacob.g10code.de> References: <87pl7b7zxh.fsf@jacob.g10code.de> Message-ID: Hey Werner, I appreciate the feedback, but I have to respectfully push back here. I don't think this is just an API inconsistency issue. I set up a minimal test case to verify what's happening, and it's pretty clear cut: // Format 2: (data (flags eddsa) (hash-algo sha512) (value %b)) err = gcry_sexp_build(&s_data, NULL, "(data (flags eddsa) (hash-algo sha512) (value %b))", msg_len, msg); err = gcry_pk_sign(&s_sig, s_data, privkey); // OK - signing works err = gcry_pk_verify(s_sig, s_data, pubkey); // FAILED - verification fails The thing is, I'm using the exact same S-expression for both signing and verification. If the format is valid enough for signing to succeed, it should be valid for verification. That's the inconsistency. You can't have signing work and verification fail with identical inputs. I get that Ed25519 has been working well since 2014 - the simple format (data (value %b)) works fine for me too. But when you add the EdDSA flags and hash-algo spec (which is what GPG uses), the verification breaks. That's a real problem. This isn't some edge case either. I'm trying to verify signatures and it fails every time because libgcrypt can sign but can't verify using the same format. For my use case, that's a showstopper for using the lib directly... I resorted to having the gpg binary do it in its own process which is not ideal code at all. I'm not trying to be difficult here - I just want this fixed or at least documented as a known limitation, and to have tests updated because in my research this bug exists because there are no tests for specifically this case. If EdDSA with hash-algo flags isn't supposed to be supported, the library should reject it at sign time, not silently accept it and then fail verification. What do you think? Did you run my example code at least and SEE the failures in your own terminal? It's reproducible, and I could show you if you were sitting in front of me. -Zachary On Thu, Jan 15, 2026 at 8:41?AM Werner Koch wrote: > Hi! > > Just a short note on your bug report. You gave a lot of examples and a > nicely formated report at https://github.com/zfogg/ascii-chat/issues/92 > but I can't read everything of it. > > On Tue, 30 Dec 2025 02:30, Zachary Fogg said: > > **In-Reply-To:** > > > Your response mentioned using `(flags eddsa)` during key generation, > which > > is good practice. However, I want to clarify that **my bug report > concerns > > signature verification, not key generation**. > > If you look at the way GnuPG uses Libgcrypt will find in > gnupg/g10/pkglue.c:pk_verify this: > > if (openpgp_oid_is_ed25519 (pkey[0])) > fmt = "(public-key(ecc(curve %s)(flags eddsa)(q%m)))"; > else > fmt = "(public-key(ecc(curve %s)(q%m)))"; > > and this for the data: > > if (openpgp_oid_is_ed25519 (pkey[0])) > fmt = "(data(flags eddsa)(hash-algo sha512)(value %m))"; > else > fmt = "(data(value %m))"; > > and more complicated stuff for re-formatting the signature data. It is > a bit unfortunate that we need to have these special cases but that's > the drawback of a having a stable API and protocol. > > > 1. Can you confirm this is a genuine bug in libgcrypt's verification > logic? > > No, at least not as I understand it. ed25519 signatures are working > well and are in active use since GnuPG 2.1 from 2014. > > > 2. Should I open a formal bug in the dev.gnupg.org tracker? > > I don't see a bug ;-) > > > 3. Would a patch fixing the PUBKEY_FLAG_PREHASH handling be acceptable? > > I do not understand exactly what you propose. A more concise > description would be helpful. But note that API stability is a primary > goal. > > BTW on your website your wrote: > > I've created a working exploit that demonstrates the severity of this > bug. The exploit proves that GPG agent creates EdDSA signatures that > cannot be verified by standard libgcrypt verification code, even with > the correct keys. > > The term "exploit" is used to describe an attack method which undermines > the security of a system. What you describe is a claimed inconsistent > API. That may or may not be the case; I don't see a security bug here, > though. > > > > Salam-Shalom, > > Werner > > > p.s. > I had a brief look at your project: In src/main.c I notice > > // Set global FPS from command-line option if provided > extern int g_max_fps; > > The declaration of an external variable inside a function is a not a > good coding style. Put this at the top of the file or into a header. > A few lines above: > > #ifndef NDEBUG > // Initialize lock debugging system after logging is fully set up > log_debug("Initializing lock debug system..."); > > Never ever use NDEBUG. This is an idea of the 70ies. This also > disables the assert(3) functionality and if you do this you won't get an > assertion failure at all in your production code - either you know the > code is correct or you are not sure. Never remove an assert from > production code. > > I have noticed a lot of documentation inside the code - that's good. > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Feb 5 02:58:25 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 05 Feb 2026 10:58:25 +0900 Subject: libgcrypt 1.8.12: STRIBOG carry overflow bug In-Reply-To: References: Message-ID: <87jywsgddq.fsf@haruna.fsij.org> Guido Vranken wrote: > Fix is in da6cd4f but was not backported to 1.8. 1.8 is EOL but has > "Extended Long Term Support contract available". Thank you. I cherry picked the commit to 1.8 branch. I found that building 1.8 is getting difficult with newer toolchain and newer libgpg-error. I push a minimal change of such a forward port, too. -- From stu at spacehopper.org Fri Feb 6 15:41:30 2026 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 6 Feb 2026 14:41:30 +0000 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 Message-ID: When building the "notmuch" email indexer, the configure script tests that gmime can extract a session key, which it does using gcrypt. Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). This is not changed by applying the patch https://lists.gnupg.org/pipermail/gcrypt-devel/2026-January/006025.html The problem is no longer seen after neutering part of https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=4f56fd8c5e03f389a9f27a5e9206b9dfb49c92e3 Index: mpi/ec.c --- mpi/ec.c.orig +++ mpi/ec.c @@ -305,7 +305,7 @@ ec_mod (gcry_mpi_t w, mpi_ec_t ec) else _gcry_mpi_mod (w, w, ec->p); - if ((ec->flags & GCRYECC_FLAG_LEAST_LEAK)) + if (0 && (ec->flags & GCRYECC_FLAG_LEAST_LEAK)) w->nlimbs = ec->p->nlimbs; } The script below replicates the test setup used by notmuch (requires gmime and gnupg to be installed). #!/bin/sh set -e tmp=$(mktemp -d /tmp/notmuchtest.XXXXXXXXX) cd $tmp cat << EOF > _check_session_keys.c #include #include int main () { GError *error = NULL; GMimeParser *parser = NULL; GMimeMultipartEncrypted *body = NULL; GMimeDecryptResult *decrypt_result = NULL; GMimeObject *output = NULL; g_mime_init (); parser = g_mime_parser_new (); g_mime_parser_init_with_stream (parser, g_mime_stream_file_open("basic-encrypted.eml", "r", &error)); if (error) return !! fprintf (stderr, "failed to instantiate parser with basic-encrypted.eml\n"); body = GMIME_MULTIPART_ENCRYPTED(g_mime_message_get_mime_part (g_mime_parser_construct_message (parser, NULL))); if (body == NULL) return !! fprintf (stderr, "did not find a multipart encrypted message\n"); output = g_mime_multipart_encrypted_decrypt (body, GMIME_DECRYPT_EXPORT_SESSION_KEY, NULL, &decrypt_result, &error); if (error || output == NULL) return !! fprintf (stderr, "decryption failed\n"); if (decrypt_result == NULL) return !! fprintf (stderr, "no GMimeDecryptResult found\n"); if (decrypt_result->session_key == NULL) return !! fprintf (stderr, "GMimeDecryptResult has no session key\n"); printf ("%s\n", decrypt_result->session_key); return 0; } EOF cat << EOF > openpgp4-secret-key.asc -----BEGIN PGP PRIVATE KEY BLOCK----- lFgEYxhtlxYJKwYBBAHaRw8BAQdA0PoNKr90DaQV1dIK77wbWm4RT+JQzqBkwIjA HQM9RHYAAQDQ5wSfkOGXvKYroALWgibztISzXS5b8boGXykcHERo6w/ctDtOb3Rt dWNoIFRlc3QgU3VpdGUgKElOU0VDVVJFISkgPHRlc3Rfc3VpdGVAbm90bXVjaG1h aWwub3JnPoiQBBMWCAA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEmjr+ bGAGWhSP1LWKfmq+kkZFzGAFAmMYbZwACgkQfmq+kkZFzGDtrwEAjQRn3xhEomah wICjQjfi4RKNbvnRViZgosijDBANUAgA/28GrK1tPnQsXWqmuZxQ1Cd5ry4NAnj/ 4jsxD3cTbnEHnF0EYxhtlxIKKwYBBAGXVQEFAQEHQEOd3EyCD5qo4+QuHz0lruCG VM6n6RI4dtAh3cX9uHwiAwEIBwAA/1oe+p5jNjNE5lEj4yTpYjCxCeC98MolbiAy 0yY7526wECqIeAQYFggAIBYhBJo6/mxgBloUj9S1in5qvpJGRcxgBQJjGG2XAhsM AAoJEH5qvpJGRcxgBdsA/R9ZECoxai5QhOitDIAUZVCRr59Pm1VMPiJOOIla2N1p AQCNESwJ9IJOdO/06q+bR2GG4WyEkB4VoVBiA3hFx/zZAA== =uGTo -----END PGP PRIVATE KEY BLOCK----- EOF cat << EOF > basic-encrypted.eml From: test_suite at notmuchmail.org To: test_suite at notmuchmail.org Subject: Here is the password Date: Sat, 01 Jan 2000 12:00:00 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/encrypted; boundary="=-=-="; protocol="application/pgp-encrypted" --=-=-= Content-Type: application/pgp-encrypted Version: 1 --=-=-= Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- hF4DHXHP849rSK8SAQdAYbv9NFaU2Fbd6JbfE87h/yZNyWLJYZ2EseU0WyOz7Agw /+KTbbIqRcEYhnpQhQXBQ2wqIN5gmdRhaqrj5q0VLV2BOKNJKqXGs/W4DghXwfAu 0oMBqjTd/mMbF0nJLw3bPX+LW47RHQdZ8vUVPlPr0ALg8kqgcfy95Qqy5h796Uyq xs+I/UUOt7fzTDAw0B4qkRbdSangwYy80N4X43KrAfKSstBH3/7O4285XZr86YhF rEtsBuwhoXI+DaG3uYZBBMTkzfButmBKHwB2CmWutmVpQL087A== =lhSz -----END PGP MESSAGE----- --=-=-=-- EOF cc $(pkg-config --cflags gmime-3.0) _check_session_keys.c \ $(pkg-config --libs gmime-3.0) -o _check_session_keys export GNUPGHOME=$tmp gpg --batch --quiet --import < openpgp4-secret-key.asc echo "cd $tmp; GNUPGHOME=$tmp ./_check_session_keys" ./_check_session_keys From wk at gnupg.org Mon Feb 9 11:32:44 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Feb 2026 11:32:44 +0100 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: (Stuart Henderson via Gcrypt-devel's message of "Fri, 6 Feb 2026 14:41:30 +0000") References: Message-ID: <87qzqub41f.fsf@jacob.g10code.de> On Fri, 6 Feb 2026 14:41, Stuart Henderson said: > When building the "notmuch" email indexer, the configure script tests > that gmime can extract a session key, which it does using gcrypt. > Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). You mean Notmuch uses its own *PGP parser to "extract" the session key? I recall that there was a discussion on speeding up things by storing decrypted session in a database and then use gpg --override-sssion-key. But I can't remember the details. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From stu at spacehopper.org Mon Feb 9 12:14:52 2026 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 9 Feb 2026 11:14:52 +0000 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: <87qzqub41f.fsf@jacob.g10code.de> References: <87qzqub41f.fsf@jacob.g10code.de> Message-ID: On 2026/02/09 11:32, Werner Koch wrote: > On Fri, 6 Feb 2026 14:41, Stuart Henderson said: > > When building the "notmuch" email indexer, the configure script tests > > that gmime can extract a session key, which it does using gcrypt. > > Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). > > You mean Notmuch uses its own *PGP parser to "extract" the session key? > > I recall that there was a discussion on speeding up things by storing > decrypted session in a database and then use gpg --override-sssion-key. > But I can't remember the details. I didn't look into how it's used in the main program code, was just hitting the failure where it's used in autoconf when building (I'm an os package builder). It does look like it's doing something along those lines in the main code though: https://git.notmuchmail.org/git?p=notmuch;a=blob;f=util/crypto.c;h=156a6550c20afef00a6bb5eaab94e8ba435cbfbd;hb=HEAD From sam at gentoo.org Mon Feb 9 17:43:31 2026 From: sam at gentoo.org (Sam James) Date: Mon, 09 Feb 2026 16:43:31 +0000 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: References: Message-ID: <87a4xhkguk.fsf@gentoo.org> Stuart Henderson via Gcrypt-devel writes: > When building the "notmuch" email indexer, the configure script tests > that gmime can extract a session key, which it does using gcrypt. > Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). Do you see anything useful if you run the reproducer under Valgrind? > [...] sam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 418 bytes Desc: not available URL: From stu at spacehopper.org Mon Feb 9 17:55:23 2026 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 9 Feb 2026 16:55:23 +0000 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: <87a4xhkguk.fsf@gentoo.org> References: <87a4xhkguk.fsf@gentoo.org> Message-ID: On 2026/02/09 16:43, Sam James wrote: > Stuart Henderson via Gcrypt-devel writes: > > > When building the "notmuch" email indexer, the configure script tests > > that gmime can extract a session key, which it does using gcrypt. > > Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). > > Do you see anything useful if you run the reproducer under Valgrind? I'm seeing this on OpenBSD, Valgrind doesn't currently work there. From sam at gentoo.org Mon Feb 9 18:14:12 2026 From: sam at gentoo.org (Sam James) Date: Mon, 09 Feb 2026 17:14:12 +0000 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: References: <87a4xhkguk.fsf@gentoo.org> Message-ID: <871pitkfff.fsf@gentoo.org> Stuart Henderson writes: > On 2026/02/09 16:43, Sam James wrote: >> Stuart Henderson via Gcrypt-devel writes: >> >> > When building the "notmuch" email indexer, the configure script tests >> > that gmime can extract a session key, which it does using gcrypt. >> > Since 1.12.0 this frequently, though not always, fails on i386 (32-bit). >> >> Do you see anything useful if you run the reproducer under Valgrind? > > I'm seeing this on OpenBSD, Valgrind doesn't currently work there. Ah, sorry for the silly question then. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 418 bytes Desc: not available URL: From gniibe at fsij.org Tue Feb 10 07:50:57 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Feb 2026 15:50:57 +0900 Subject: libgcrypt 1.12.0: g_mime_multipart_encrypted_decrypt failing on i386 In-Reply-To: References: Message-ID: <87wm0lytv2.fsf@haruna.fsij.org> Hello, Thank you for your report. Stuart Henderson wrote: > The script below replicates the test setup used by notmuch (requires > gmime and gnupg to be installed). I build gnupg from master for i386 on a Debian machine (also build npth, libgpg-error, libgcrypt, libassuan, libksba, and ntbtls). With this newly built gpg, I can't replicate the failure by running the _check_session_keys program many times. (I make sure using the newly built gnupg i386 version with libgcrypt 1.12.) Manually decrypting the message (basic-encrypted.eml), by the newly built gnupg, also gets success. I can't replicate any failure. Could you please narrow down the failure? IIUC, when the _check_session_keys program fails, invoking gpg must fail too. If so, debug output of gpg (and/or gpg-agent) helps. --