From sam at gentoo.org  Sun Jan  4 03:11:28 2026
From: sam at gentoo.org (Sam James)
Date: Sun,  4 Jan 2026 02:11:28 +0000
Subject: [PATCH GnuPG] Fix -Wlto-type-mismatch warnings [T4416]
Message-ID: <4cc541d6db5198d5f01860b228d09f26b5692479.1767492688.git.sam@gentoo.org>

* agent/t-protect.c (convert_from_openpgp_native): Sync stub definition.
* g10/gpgv.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(struct keyserver_spec): Ditto.
(parse_keyserver_uri): Ditto.
(keyserver_export_pubkey): Ditto.
(show_photos): Ditto.
* g10/test-stubs.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(parse_keyserver_uri): Ditto.
(show_photos): Ditto.

--

GnuPG-bug-id: 4416

When building with GCC -flto, some warnings appear because of
mismatched definitions in stubs (gpgv or tests). Sync them with the
real definitions to fix the warnings, as they just drifted over time.

Signed-off-by: Sam James <sam at gentoo.org>
---
DCO at https://lists.gnupg.org/pipermail/gnupg-devel/2025-August/036044.html

 agent/t-protect.c |  7 +++++--
 g10/gpgv.c        | 49 +++++++++++++++++++++++++++++++----------------
 g10/test-stubs.c  | 37 ++++++++++++++++++++++-------------
 3 files changed, 62 insertions(+), 31 deletions(-)

diff --git a/agent/t-protect.c b/agent/t-protect.c
index e6edbffba..95452eb29 100644
--- a/agent/t-protect.c
+++ b/agent/t-protect.c
@@ -341,9 +341,12 @@ main (int argc, char **argv)
 
 /* Stub function.  */
 gpg_error_t
-convert_from_openpgp_native (gcry_sexp_t s_pgp, const char *passphrase,
-                             unsigned char **r_key)
+convert_from_openpgp_native (ctrl_t ctrl,
+                                         gcry_sexp_t s_pgp,
+                                         const char *passphrase,
+                                         unsigned char **r_key)
 {
+  (void)ctrl;
   (void)s_pgp;
   (void)passphrase;
   (void)r_key;
diff --git a/g10/gpgv.c b/g10/gpgv.c
index b65dfa66b..f5bd404ed 100644
--- a/g10/gpgv.c
+++ b/g10/gpgv.c
@@ -462,10 +462,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+                            struct keyserver_spec *keyserver,
+                            unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -493,9 +496,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+                           unsigned char **fpr,size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -511,11 +519,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (const char *name,struct keyserver_spec *spec)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+                                   unsigned char **fpr,size_t *fpr_len,
+                                   struct keyserver_spec *keyserver,
+                                   unsigned int flags)
 {
-  (void)name;
-  (void)spec;
+  (void)ctrl;
+  (void)mbox;
+  (void)fpr;
+  (void)fpr_len;
+  (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -647,15 +662,14 @@ parse_preferred_keyserver(PKT_signature *sig)
   return NULL;
 }
 
-struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+gpg_error_t
+keyserver_export_pubkey (ctrl_t ctrl, PKT_public_key *pk,
+                                     int assume_new_key)
 {
-  (void)uri;
-  (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
-  return NULL;
+  (void)ctrl;
+  (void)pk;
+  (void)assume_new_key;
+  return 0;
 }
 
 void
@@ -666,11 +680,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+                  PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
diff --git a/g10/test-stubs.c b/g10/test-stubs.c
index 9b41c8929..f00f31808 100644
--- a/g10/test-stubs.c
+++ b/g10/test-stubs.c
@@ -193,10 +193,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+                            struct keyserver_spec *keyserver,
+                            unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -224,9 +227,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+                           unsigned char **fpr,size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -242,15 +250,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (ctrl_t ctrl, const char *mbox, unsigned char **fpr,
-                       size_t *fprlen, struct keyserver_spec *keyserver)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+                                   unsigned char **fpr,size_t *fpr_len,
+                                   struct keyserver_spec *keyserver,
+                                   unsigned int flags)
 {
   (void)ctrl;
   (void)mbox;
   (void)fpr;
-  (void)fprlen;
+  (void)fpr_len;
   (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -382,13 +393,10 @@ parse_preferred_keyserver(PKT_signature *sig)
 }
 
 struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+parse_keyserver_uri (const char *string, int require_scheme)
 {
-  (void)uri;
+  (void)string;
   (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
   return NULL;
 }
 
@@ -400,11 +408,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+                  PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
-- 
2.52.0



From sam at gentoo.org  Sun Jan  4 06:18:24 2026
From: sam at gentoo.org (Sam James)
Date: Sun,  4 Jan 2026 05:18:24 +0000
Subject: [PATCH GnuPG v2] Fix -Wlto-type-mismatch warnings [T4416]
In-Reply-To: <4cc541d6db5198d5f01860b228d09f26b5692479.1767492688.git.sam@gentoo.org>
References: <4cc541d6db5198d5f01860b228d09f26b5692479.1767492688.git.sam@gentoo.org>
Message-ID: <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>

* agent/t-protect.c (convert_from_openpgp_native): Sync stub definition.
* g10/gpgv.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(struct keyserver_spec): Ditto.
(parse_keyserver_uri): Ditto.
(keyserver_export_pubkey): Ditto.
(show_photos): Ditto.
* g10/test-stubs.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(parse_keyserver_uri): Ditto.
(show_photos): Ditto.

--

GnuPG-bug-id: 4416

When building with GCC -flto, some warnings appear because of
mismatched definitions in stubs (gpgv or tests). Sync them with the
real definitions to fix the warnings, as they just drifted over time.

Signed-off-by: Sam James <sam at gentoo.org>
---
v2: Fixed formatting.

 agent/t-protect.c |  7 +++++--
 g10/gpgv.c        | 49 +++++++++++++++++++++++++++++++----------------
 g10/test-stubs.c  | 37 ++++++++++++++++++++++-------------
 3 files changed, 62 insertions(+), 31 deletions(-)

diff --git a/agent/t-protect.c b/agent/t-protect.c
index e6edbffba..9508de36a 100644
--- a/agent/t-protect.c
+++ b/agent/t-protect.c
@@ -341,9 +341,12 @@ main (int argc, char **argv)
 
 /* Stub function.  */
 gpg_error_t
-convert_from_openpgp_native (gcry_sexp_t s_pgp, const char *passphrase,
-                             unsigned char **r_key)
+convert_from_openpgp_native (ctrl_t ctrl,
+			     gcry_sexp_t s_pgp,
+			     const char *passphrase,
+			     unsigned char **r_key)
 {
+  (void)ctrl;
   (void)s_pgp;
   (void)passphrase;
   (void)r_key;
diff --git a/g10/gpgv.c b/g10/gpgv.c
index b65dfa66b..065f06db4 100644
--- a/g10/gpgv.c
+++ b/g10/gpgv.c
@@ -462,10 +462,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+			struct keyserver_spec *keyserver,
+			unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -493,9 +496,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+		       unsigned char **fpr,size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -511,11 +519,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (const char *name,struct keyserver_spec *spec)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+		       unsigned char **fpr,size_t *fpr_len,
+		       struct keyserver_spec *keyserver,
+		       unsigned int flags)
 {
-  (void)name;
-  (void)spec;
+  (void)ctrl;
+  (void)mbox;
+  (void)fpr;
+  (void)fpr_len;
+  (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -647,15 +662,14 @@ parse_preferred_keyserver(PKT_signature *sig)
   return NULL;
 }
 
-struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+gpg_error_t
+keyserver_export_pubkey (ctrl_t ctrl, PKT_public_key *pk,
+			 int assume_new_key)
 {
-  (void)uri;
-  (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
-  return NULL;
+  (void)ctrl;
+  (void)pk;
+  (void)assume_new_key;
+  return 0;
 }
 
 void
@@ -666,11 +680,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+	     PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
diff --git a/g10/test-stubs.c b/g10/test-stubs.c
index 9b41c8929..7b9af8470 100644
--- a/g10/test-stubs.c
+++ b/g10/test-stubs.c
@@ -193,10 +193,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+			struct keyserver_spec *keyserver,
+			unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -224,9 +227,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+		       unsigned char **fpr, size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -242,15 +250,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (ctrl_t ctrl, const char *mbox, unsigned char **fpr,
-                       size_t *fprlen, struct keyserver_spec *keyserver)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+		       unsigned char **fpr,size_t *fpr_len,
+		       struct keyserver_spec *keyserver,
+		       unsigned int flags)
 {
   (void)ctrl;
   (void)mbox;
   (void)fpr;
-  (void)fprlen;
+  (void)fpr_len;
   (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -382,13 +393,10 @@ parse_preferred_keyserver(PKT_signature *sig)
 }
 
 struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+parse_keyserver_uri (const char *string, int require_scheme)
 {
-  (void)uri;
+  (void)string;
   (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
   return NULL;
 }
 
@@ -400,11 +408,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+	     PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
-- 
2.52.0



From mario.haustein at hrz.tu-chemnitz.de  Sun Jan  4 17:07:33 2026
From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein)
Date: Sun, 04 Jan 2026 17:07:33 +0100
Subject: [PATCH GnuPG 2/2] scd:p15: Add support for D-Trust Card 6.1/6.4
Message-ID: <2488114.NG923GbCHz@localdomain>

* scd/app-p15.c (CARD_TYPE_STARCOS_37): New.
(CARD_PRODUCT_DTRUST6): New.
(read_p15_info): Add workaround for wrongly encoded PIN reference in
EF.AOD
(prepare_verify_pin): Use select_df_by_path to select application, as
the card operating system doesn't support path-based selections.
(do_sign): Support for key reference IDs longer than one byte.

Signed-off-by: Mario Haustein <mario.haustein at hrz.tu-chemnitz.de>
---
 scd/app-p15.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 97 insertions(+), 5 deletions(-)

diff --git a/scd/app-p15.c b/scd/app-p15.c
index d12179bb4..4e187b364 100644
--- a/scd/app-p15.c
+++ b/scd/app-p15.c
@@ -77,7 +77,8 @@ typedef enum
     CARD_TYPE_CARDOS_54,
     CARD_TYPE_AET,     /* A.E.T. Europe JCOP card.  */
     CARD_TYPE_BELPIC,  /* Belgian eID card specs. */
-    CARD_TYPE_STARCOS_32
+    CARD_TYPE_STARCOS_32,
+    CARD_TYPE_STARCOS_37
   }
 card_type_t;
 
@@ -90,6 +91,7 @@ typedef enum
     CARD_PRODUCT_RSCS,     /* Rohde&Schwarz Cybersecurity       */
     CARD_PRODUCT_DTRUST3,  /* D-Trust GmbH (bundesdruckerei.de) */
     CARD_PRODUCT_DTRUST4,
+    CARD_PRODUCT_DTRUST6,
     CARD_PRODUCT_GENUA,    /* GeNUA mbH                         */
     CARD_PRODUCT_NEXUS,    /* Technology Nexus                  */
     CARD_PRODUCT_CVISION   /* Cryptovision GmbH                 */
@@ -135,6 +137,9 @@ static struct
   { 25, X("\x3b\x9f\x96\x81\xb1\xfe\x45\x1f\x07\x00\x64\x05"
           "\x1e\xb2\x00\x31\xb0\x73\x96\x21\xdb\x05\x90\x00\x5c"),
     CARD_TYPE_STARCOS_32 },
+  { 21, X("\x3b\xda\x96\xff\x81\xb1\xfe\x45\x1f\x07\x80\x58"
+          "\x44\x54\x52\x20\x56\x31\x2e\x31\xe2"),
+    CARD_TYPE_STARCOS_37 },
   { 0 }
 };
 #undef X
@@ -144,7 +149,8 @@ static struct
 #define IS_CARDOS_5(a) ((a)->app_local->card_type == CARD_TYPE_CARDOS_50 \
                         || (a)->app_local->card_type == CARD_TYPE_CARDOS_53 \
                         || (a)->app_local->card_type == CARD_TYPE_CARDOS_54)
-#define IS_STARCOS_3(a) ((a)->app_local->card_type == CARD_TYPE_STARCOS_32)
+#define IS_STARCOS_3(a) ((a)->app_local->card_type == CARD_TYPE_STARCOS_32 \
+                         || (a)->app_local->card_type == 
CARD_TYPE_STARCOS_37)
 
 
 /* The default PKCS-15 home DF */
@@ -560,6 +566,7 @@ cardtype2str (card_type_t cardtype)
     case CARD_TYPE_BELPIC:    return "Belgian eID";
     case CARD_TYPE_AET:       return "AET";
     case CARD_TYPE_STARCOS_32:return "STARCOS 3.2";
+    case CARD_TYPE_STARCOS_37:return "STARCOS 3.7";
     }
   return "";
 }
@@ -573,6 +580,7 @@ cardproduct2str (card_product_t cardproduct)
     case CARD_PRODUCT_RSCS:    return "R&S";
     case CARD_PRODUCT_DTRUST3: return "D-Trust 3";
     case CARD_PRODUCT_DTRUST4: return "D-Trust 4.1/4.4";
+    case CARD_PRODUCT_DTRUST6: return "D-Trust 6.1/6.4";
     case CARD_PRODUCT_GENUA:   return "GeNUA";
     case CARD_PRODUCT_NEXUS:   return "Nexus";
     case CARD_PRODUCT_CVISION: return "Cryptovison";
@@ -872,13 +880,11 @@ select_ef_by_path (app_t app, const unsigned short 
*path, size_t pathlen)
 }
 
 
-#if 0 /* Currently not used.  */
 static gpg_error_t
 select_df_by_path (app_t app, const unsigned short *path, size_t pathlen)
 {
   return select_by_path (app, path, pathlen, 1);
 }
-#endif
 
 
 /* Parse a cert Id string (or a key Id string) and return the binary
@@ -3921,6 +3927,37 @@ read_p15_info (app_t app)
     {
       app->app_local->card_product = CARD_PRODUCT_DTRUST4;
     }
+  if (!app->app_local->card_product
+      && app->app_local->token_label
+      && !strncmp (app->app_local->token_label, "D-TRUST Card 6.", 15)
+      && app->app_local->card_type == CARD_TYPE_STARCOS_37)
+    {
+      aodf_object_t aodf;
+
+      app->app_local->card_product = CARD_PRODUCT_DTRUST6;
+
+      for (prkdf = app->app_local->private_key_info; prkdf; prkdf = prkdf-
>next)
+        {
+          /* The card supports only OAEP and ECIES decryption, which are not
+           * supported by GnuPG right now. Thus we mask the respectiv usage
+           * flags. */
+          prkdf->usageflags.decrypt = 0;
+          prkdf->usageflags.unwrap = 0;
+          prkdf->usageflags.derive = 0;
+        }
+
+      for (aodf = app->app_local->auth_object_info; aodf; aodf = aodf->next)
+        if (aodf->auth_type == AUTH_TYPE_PIN
+            && aodf->pin_reference_valid
+            && aodf->label != NULL
+            && !strcmp(aodf->label, "Authentication-PIN"))
+          {
+            /* D-Trust encoded the wrong PIN reference in EF.AOD so we have 
to
+             * workaround it. */
+            aodf->pin_reference = 0x82;
+            break;
+          }
+    }
 
 
   /* Now print the info about the PrKDF.  */
@@ -5130,6 +5167,16 @@ prepare_verify_pin (app_t app, const char *keyref,
         log_error ("p15: error selecting PKCS#15 AID for key %s: %s\n",
                    keyref, gpg_strerror (err));
     }
+  else if (prkdf && app->app_local->card_product == CARD_PRODUCT_DTRUST6)
+    {
+      /* The card operating system does not support selecting the application
+       * by direct path selection. We need to select all file ids as a
+       * directory file. */
+      err = select_df_by_path (app, prkdf->path, prkdf->pathlen);
+      if (err)
+        log_error ("p15: error selecting directory file for key %s: %s\n",
+                   keyref, gpg_strerror (err));
+    }
   else if (prkdf)
     {
       /* Standard case: Select the key file.  Note that this may
@@ -5731,7 +5778,8 @@ do_sign (app_t app, ctrl_t ctrl, const char *keyidstr, 
int hashalgo,
         }
       if (app->app_local->card_type == CARD_TYPE_BELPIC
           || app->app_local->card_product == CARD_PRODUCT_NEXUS
-          || app->app_local->card_product == CARD_PRODUCT_DTRUST4)
+          || app->app_local->card_product == CARD_PRODUCT_DTRUST4
+          || app->app_local->card_product == CARD_PRODUCT_DTRUST6)
         {
           /* The default for these cards is to use a plain hash.  We
            * assume that due to the used certificate the correct hash
@@ -5859,6 +5907,50 @@ do_sign (app_t app, ctrl_t ctrl, const char *keyidstr, 
int hashalgo,
                                                0xf3, 0x25, NULL, 0);
         }
     }
+  else if (app->app_local->card_product == CARD_PRODUCT_DTRUST6)
+    {
+      unsigned char mse[10];
+
+      i = 0;
+      err = 0;
+
+      /* D-Trust-Card uses 3 byte long (negative) key reference IDs */
+      mse[i++] = 0x84; /* Key reference. */
+      mse[i++] = 3;
+      mse[i++] = (prkdf->key_reference >> 16) & 0xff;
+      mse[i++] = (prkdf->key_reference >>  8) & 0xff;
+      mse[i++] =  prkdf->key_reference        & 0xff;
+
+      if (prkdf->is_ecc)
+        {
+          mse[i++] = 0x89;
+          mse[i++] = 2;
+          mse[i++] = 0x13;
+          mse[i++] = 0x35;
+        }
+      else
+        {
+          mse[i++] = 0x89; /* Algorithm reference (BCD encoded).  */
+          mse[i++] = 3;
+          mse[i++] = 0x13; /* RSA PKCS#1 (standard) (1 3 2 3).  */
+          mse[i++] = 0x23;
+          switch (hashalgo)
+            {
+            case GCRY_MD_SHA1:   mse[i++] = 0x10; break;
+            case GCRY_MD_RMD160: mse[i++] = 0x20; break;
+            case GCRY_MD_SHA256: mse[i++] = 0x30; break;
+            case GCRY_MD_SHA384: mse[i++] = 0x40; break;
+            case GCRY_MD_SHA512: mse[i++] = 0x50; break;
+            case GCRY_MD_SHA224: mse[i++] = 0x60; break;
+            default: err = gpg_error (GPG_ERR_DIGEST_ALGO); break;
+            }
+        }
+
+      log_assert (i <= DIM(mse));
+      if (!err)
+        err = iso7816_manage_security_env (app_get_slot (app), 0x41, 0xB6,
+                                               mse, i);
+    }
   else if (app->app_local->card_product == CARD_PRODUCT_CVISION)
     {
       /* I can't make the Starcos 3.2 work the correct way, so let's
-- 
2.52.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260104/9cd24a35/attachment-0001.sig>

From mario.haustein at hrz.tu-chemnitz.de  Sun Jan  4 17:06:54 2026
From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein)
Date: Sun, 04 Jan 2026 17:06:54 +0100
Subject: [PATCH GnuPG 1/2] scd: allow to query FCP when selecting an
 application
Message-ID: <3758773.R56niFO833@localdomain>

* scd/iso7816.c (iso7816_select_application_ext): Add flag die query FCP
* scd/iso7816.h: define new response type flags
* scd/app.c: apply new flags
* scd/app-piv.c: ditto
* scd/app-p15.c: query FCI during application selection and fallback to
  FCP if file ID tag 0x83 is not found.

--
Some cards (for example STARCOS 3.7 based D-Trust Cards 6.1/6.4) don't
return the file ID of the application in the FCI response of the SELECT
command (P2=0x00). Instead the file ID is only returned if the FCP is
queried in the SELECT command (P2=0x04).

If the file ID is not returned in the FCI, we will fall back to the FCP
and then to the default home file ID if the FCP also fails.

Signed-off-by: Mario Haustein <mario.haustein at hrz.tu-chemnitz.de>
---
 scd/app-p15.c | 48 +++++++++++++++++++++++++++++++++++++++++-------
 scd/app-piv.c |  4 ++--
 scd/app.c     |  2 +-
 scd/iso7816.c | 15 +++++++++++++--
 scd/iso7816.h |  5 +++++
 5 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/scd/app-p15.c b/scd/app-p15.c
index f5c5f7a17..d12179bb4 100644
--- a/scd/app-p15.c
+++ b/scd/app-p15.c
@@ -6431,6 +6431,8 @@ app_select_p15 (app_t app)
 {
   int slot = app_get_slot (app);
   int rc;
+  const char *aid;
+  size_t aidlen;
   unsigned short def_home_df = 0;
   card_type_t card_type = CARD_TYPE_UNKNOWN;
   int direct = 0;
@@ -6438,14 +6440,17 @@ app_select_p15 (app_t app)
   unsigned char *fci = NULL;
   size_t fcilen;
 
-  rc = iso7816_select_application_ext (slot, pkcs15_aid, sizeof pkcs15_aid, 
1,
-                                       &fci, &fcilen);
+  aid = pkcs15_aid;
+  aidlen = sizeof pkcs15_aid;
+  rc = iso7816_select_application_ext (slot, aid, aidlen,
+                                       ISO7816_SELECT_FCI, &fci, &fcilen);
   if (rc)
     {
       /* D-TRUST Card 4.x uses a different AID. */
-      rc = iso7816_select_application_ext (slot, pkcs15dtrust4_aid,
-                                           sizeof pkcs15dtrust4_aid, 1,
-                                           &fci, &fcilen);
+      aid = pkcs15dtrust4_aid;
+      aidlen = sizeof pkcs15dtrust4_aid;
+      rc = iso7816_select_application_ext (slot, aid, aidlen,
+                                           ISO7816_SELECT_FCI, &fci, 
&fcilen);
     }
   if (rc)
     { /* Not found: Try to locate it from 2F00.  We use direct path
@@ -6516,7 +6521,7 @@ app_select_p15 (app_t app)
           goto leave;
         }
 
-      /* Set the home DF from the FCI returned by the select.  */
+      /* Set the home DF from the FCI returned by the select. */
       if (!def_home_df && fci)
         {
           const unsigned char *s;
@@ -6525,14 +6530,43 @@ app_select_p15 (app_t app)
           s = find_tlv (fci, fcilen, 0x83, &n);
           if (s && n == 2)
             def_home_df = buf16_to_ushort (s);
+          else if (fcilen)
+            {
+              log_printhex (fci, fcilen, "fci:");
+              log_info ("p15: select did not return the DF - querying 
FCP\n");
+            }
+        }
+
+      /* Set the home DF from the FCP returned by the select, when not 
already
+       * contained in the FCI. STARCOS 3.7 (at least the D-Trust Card 6.1/6.4
+       * requires to request FCP instead of FCI. */
+      if (!def_home_df)
+        {
+          const unsigned char *s;
+          size_t n;
+
+          xfree (fci);
+
+          fci = NULL;
+          fcilen = 0;
+          rc = iso7816_select_application_ext (slot, aid, aidlen,
+                                               ISO7816_SELECT_FCP, &fci, 
&fcilen);
+
+          if (!rc && fci)
+            {
+              s = find_tlv (fci, fcilen, 0x83, &n);
+              if (s && n == 2)
+                def_home_df = buf16_to_ushort (s);
+            }
           else
             {
               if (fcilen)
-                log_printhex (fci, fcilen, "fci:");
+                log_printhex (fci, fcilen, "fcp:");
               log_info ("p15: select did not return the DF - using 
default\n");
               def_home_df = DEFAULT_HOME_DF;
             }
         }
+
       app->app_local->home_df = def_home_df;
 
       /* Store the card type.  FIXME: We might want to put this into
diff --git a/scd/app-piv.c b/scd/app-piv.c
index f35815e58..a5f2d6219 100644
--- a/scd/app-piv.c
+++ b/scd/app-piv.c
@@ -3684,8 +3684,8 @@ app_select_piv (app_t app)
   /* Note that we select using the AID without the 2 octet version
    * number.  This allows for better reporting of future specs.  We
    * need to use the use-zero-for-P2-flag.  */
-  err = iso7816_select_application_ext (slot, piv_aid, sizeof piv_aid, 
0x0001,
-                                        &apt, &aptlen);
+  err = iso7816_select_application_ext (slot, piv_aid, sizeof piv_aid,
+                                        ISO7816_SELECT_FCI, &apt, &aptlen);
   if (err)
     goto leave;
 
diff --git a/scd/app.c b/scd/app.c
index f08067e87..0329d3fb0 100644
--- a/scd/app.c
+++ b/scd/app.c
@@ -792,7 +792,7 @@ app_new_register (int slot, ctrl_t ctrl, const char *name,
                       buf = NULL;
                       if (!iso7816_select_application_ext (slot,
                                                        otp_aid, sizeof 
otp_aid,
-                                                       1, &buf, &buflen)
+                                                       ISO7816_SELECT_FCI, 
&buf, &buflen)
                           && buflen > 3)
                         card->cardversion = ((buf[0]<<16)|(buf[1]<<8)|
buf[2]);
                     }
diff --git a/scd/iso7816.c b/scd/iso7816.c
index 6634cd4a7..533e579de 100644
--- a/scd/iso7816.c
+++ b/scd/iso7816.c
@@ -152,9 +152,20 @@ iso7816_select_application_ext (int slot, const char 
*aid, size_t aidlen,
                                 unsigned int flags,
                                 unsigned char **result, size_t *resultlen)
 {
+  int p2;
   int sw;
-  sw = apdu_send (slot, 0, 0x00, CMD_SELECT_FILE, 4,
-                  (flags&1)? 0:0x0c, aidlen, aid,
+
+  switch (flags)
+    {
+    case ISO7816_SELECT_FCI: p2 = 0x00; break;
+    case ISO7816_SELECT_FCP: p2 = 0x04; break;
+    case ISO7816_SELECT_NORESP:
+    default:
+      p2 = 0x0c;
+    }
+
+  sw = apdu_send (slot, 0, 0x00, CMD_SELECT_FILE, 4, p2,
+                  aidlen, aid,
                   result, resultlen);
   return map_sw (sw);
 }
diff --git a/scd/iso7816.h b/scd/iso7816.h
index 67b9f47ab..aef5c2092 100644
--- a/scd/iso7816.h
+++ b/scd/iso7816.h
@@ -29,6 +29,11 @@
 #define ISO7816_CHANGE_REFERENCE_DATA 0x24
 #define ISO7816_RESET_RETRY_COUNTER   0x2C
 
+/* Flags to encode which data should be returned by SELECT */
+#define ISO7816_SELECT_NORESP  0       /* no response to SELECT */
+#define ISO7816_SELECT_FCI     1       /* query FCI (file control 
information) by SELECT */
+#define ISO7816_SELECT_FCP     2       /* query FCP (file control parameters) 
by SELECT */
+
 /* Error codes returned by iso7816_verify_status.  A non-negative
  * number gives the number of left tries.
  * NB: The values are also used by the CHV-STATUS lines and thus are
-- 
2.52.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260104/975a1199/attachment.sig>

From mario.haustein at hrz.tu-chemnitz.de  Sun Jan  4 17:06:18 2026
From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein)
Date: Sun, 04 Jan 2026 17:06:18 +0100
Subject: [PATCH GnuPG 0/2] Add support for D-Trust Card 6.1/6.4
Message-ID: <1974271.CQOukoFCf9@localdomain>

Dear GnuPG maintainers,

attached you will find a series of patches which adds support for D-Trust 
electronic Signature and Sealing Cards version 6.1/6.4.

To get the cards working some minor changes on the ISO7816 layer were 
necessary. The PKCS#15 application has to be selected by its AID, but is later 
selected by its file ID to retrieve data about keys, authentication objects, 
certificates and so on. The file ID is retrieved from the FCI response of the 
initial SELECT. This kind of D-Trust Cards (maybe this holds for all cards of 
the underlying STARCOS 3.7 card operating system) doesn't return the file ID 
tag in the FCI. The tag is only returned in the FCP response. Thus I had to 
alter iso7816_select_application_ext() such that it is possible to select 
which response is requested.

With this patch, the PKCS#15 driver will continue to use the FCI and just fall 
back to the FCP if the tag is not present in the FCI. This introduces a bit of 
complexity, but reduces the chance of introducing a regression. According to 
ISO 7816 part 4 the file ID is part of the file parameters so querying just 
the FCP seems to be sufficient from my point. I can prepare a more simpler 
patch for this, but don't have a representative set of cards to prove this 
assumption.

The rest of the driver is implemented straight-forward. Just the encoding of 
the key reference in EF.PrKD made it necessary to introduce a further case in 
do_sign().

The card issuer chose a key reference number whose ASN.1 representation is 3 
byte long. But the current STARCOS-case in do_sign() assumes a 1 byte long 
reference. It further doesn't implement the EC-ciphers. As I am not sure 
whether all STARCOS-cards supports ECC, it was the safest option to introduce 
a new case with hard coded key reference length and implemented ECC support. 
Merging these two cases nevertheless would be possible. But I do not have 
access to other STARCOS-cards for testing.

Kind regards
Mario Haustein


Mario Haustein (2):
  scd: allow to query FCP when selecting an application
  scd:p15: Add support for D-Trust Card 6.1/6.4

 scd/app-p15.c | 150 ++++++++++++++++++++++++++++++++++++++++++++++----
 scd/app-piv.c |   4 +-
 scd/app.c     |   2 +-
 scd/iso7816.c |  15 ++++-
 scd/iso7816.h |   5 ++
 5 files changed, 159 insertions(+), 17 deletions(-)

-- 
2.52.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260104/26d03922/attachment.sig>

From sachin.t at ibm.com  Mon Jan  5 09:16:55 2026
From: sachin.t at ibm.com (Sachin T)
Date: Mon, 5 Jan 2026 08:16:55 +0000
Subject: [PATCH libassuan] Add fixes to support IBM z/OS platform.
Message-ID: <CO1PR15MB50035195BBD6D625D92E212B9786A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hi Maintainers,

Please review patch required for libassuan on IBM z/OS platform.

Patch details -
* m4/libtool.m4: use pass_all dependency checking on z/OS.
* src/assuan-socket.c: Include sys/time.h header which defines fd_set, struct timeval.

Regards,
Sachin

---

* m4/libtool.m4: use pass_all dependency checking on z/OS.
* src/assuan-socket.c: Include sys/time.h header which defines fd_set, struct timeval

Signed-off-by: Sachin T <sachin.t at ibm.com>
---
 m4/libtool.m4       | 4 ++++
 src/assuan-socket.c | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c6f534e..720d2bd 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3348,6 +3348,10 @@ openbsd*)
   fi
   ;;

+openedition*)
+  lt_cv_deplibs_check_method=pass_all
+  ;;
+
 osf3* | osf4* | osf5*)
   lt_cv_deplibs_check_method=pass_all
   ;;
diff --git a/src/assuan-socket.c b/src/assuan-socket.c
index 4c859a5..b33f575 100644
--- a/src/assuan-socket.c
+++ b/src/assuan-socket.c
@@ -48,6 +48,10 @@
 #include "assuan-defs.h"
 #include "debug.h"

+#ifdef __MVS__
+#include <sys/time.h>
+#endif
+
 /* Hacks for Slowaris.  */
 #ifndef PF_LOCAL
 # ifdef PF_UNIX
--
2.51.2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260105/e304228a/attachment-0001.html>

From andrewg at andrewg.com  Mon Jan  5 14:55:36 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 5 Jan 2026 13:55:36 +0000
Subject: Undocumented novel Ed448 point encoding breaks interoperability
Message-ID: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com>

Hi,

It has been brought to my attention that Ed448 keys are being encoded 
without prefix octets in their MPIs/SOSes, which breaks compatibility 
with go-crypto (and perhaps others) and is not documented anywhere that 
I can find. The librepgp specification requires prefix octets for all 
ECC curve point representations.

The offending code appears to be in libgcrypt/cipher/ecc.c:

```
rc = _gcry_ecc_eddsa_encodepoint (ec->Q, ec, Gx, Gy,
                                   (ec->dialect != ECC_DIALECT_SAFECURVE
                                    && !!(flags & PUBKEY_FLAG_COMP)),
                                   &encpk, &encpklen);
```

https://github.com/gpg/libgcrypt/blob/9e3af928ee1100fc979a75dd4ae6a4ace2c36bef/cipher/ecc.c#L775

This selectively uses prefix octets (or not) depending on the value of 
`ec->dialect`, which is only set to `ECC_DIALECT_SAFECURVE` for ed448. 
This means that ed448 curve points are noncompliant with section 13.3 of 
the librepgp specification, which reads:

> The EdDSA algorithm defines a specific point compression format. To indicate the use of this compression format and to make sure that the key can be represented in the Multiprecision Integer (MPI) format the octet string specifying the point is prefixed with the octet 0x40. This encoding is an extension of the encoding given in [SEC1] which uses 0x04 to indicate an uncompressed point. For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key.

https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-eddsa-point-format

Ed25519 follows the above spec, but Ed448 does not. Is this an error in 
the specification or an error in the implementation?

A



From m at the13thletter.info  Mon Jan  5 20:42:44 2026
From: m at the13thletter.info (Marco Ricci)
Date: Mon, 5 Jan 2026 20:42:44 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <87ikdppmyp.fsf@jacob.g10code.de>
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
 <87ms31pnnl.fsf@jacob.g10code.de> <87ikdppmyp.fsf@jacob.g10code.de>
Message-ID: <a92da4ad-2a32-4d4b-8244-0ca15eec1734@the13thletter.info>

Dear GnuPG developers, dear Werner.

Thus spoke Werner Koch:
> Regarding OpenSSH support on Windows please checkout [the last comment
> on] https://dev.gnupg.org/T3883
> 
> [...]
> 
> I forgot to mention that you start gpg-agent and thus ssh support
> using
> 
>   gpgconf --launch gpg-agent
> 
> or just use "gpg -K" which launches the gpg-agent as a side-effect.

I have since resolved my underlying problem (spawning gpg-agent with
OpenSSH emulation support) directly; it turned out to be user error.
I have multiple copies of GnuPG (via MSYS, via Git, via gpg4win)
installed, at different versions and with different home directories,
and apparently, I was using one of the outdated copies that did not yet
implement OpenSSH emulation.  Using the current GnuPG 2.4.8 from gpg4win
manually while double-checking that the correct binaries and the correct
home directory is used, I can successfully launch `gpg-agent` with
OpenSSH emulation by putting `enable-win32-openssh-support` manually
into the `gpg-agent.conf` file, then calling `gpg-connect-agent /bye`.

That said, regarding your reply: I was specifically asking for the
correct, documented way to pass command-line arguments to the invocation
of `gpg-agent`, because I wanted to debug whether I was launching
`gpg-agent` correctly.  The manual page for `gpg-agent` (Section 2.2
"Option Summary") seemed to suggest that it is possible to put options
"on the command line" (which I could not get to work) "or, after
stripping off the two leading dashes, in the configuration file" (which
ultimately worked for me, after sorting out the confusion concerning the
multiple versions and home directories).  Thus, my question.

I have encountered further... quirks concerning `gpg-agent` and
`gpgconf`, but those probably make more sense to report in your issue
tracker, not this mailing list.

Cheers,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 325 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260105/8b8c1789/attachment.sig>

From sam at gentoo.org  Tue Jan  6 03:54:23 2026
From: sam at gentoo.org (Sam James)
Date: Tue,  6 Jan 2026 02:54:23 +0000
Subject: [PATCH GnuPG v3] Fix -Wlto-type-mismatch warnings [T4416]
In-Reply-To: <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>
References: <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>
Message-ID: <27d9f0aab7c50339b9c8e9dbf66072bdf718d27c.1767668063.git.sam@gentoo.org>

* agent/t-protect.c (convert_from_openpgp_native): Sync stub definition.
* g10/gpgv.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(parse_keyserver_uri): Ditto.
(show_photos): Ditto.
* g10/test-stubs.c (keyserver_import_keyid): Sync stub definition.
(keyserver_import_cert): Ditto.
(keyserver_import_mbox): Ditto.
(parse_keyserver_uri): Ditto.
(show_photos): Ditto.

--

GnuPG-bug-id: 4416

When building with GCC -flto, some warnings appear because of
mismatched definitions in stubs (gpgv or tests). Sync them with the
real definitions to fix the warnings, as they just drifted over time.

Signed-off-by: Sam James <sam at gentoo.org>
---
v3: Fix a copypasto.
v2: Fix formatting.

 agent/t-protect.c |  7 +++++--
 g10/gpgv.c        | 42 +++++++++++++++++++++++++++++-------------
 g10/test-stubs.c  | 37 ++++++++++++++++++++++++-------------
 3 files changed, 58 insertions(+), 28 deletions(-)

diff --git a/agent/t-protect.c b/agent/t-protect.c
index e6edbffba..9508de36a 100644
--- a/agent/t-protect.c
+++ b/agent/t-protect.c
@@ -341,9 +341,12 @@ main (int argc, char **argv)
 
 /* Stub function.  */
 gpg_error_t
-convert_from_openpgp_native (gcry_sexp_t s_pgp, const char *passphrase,
-                             unsigned char **r_key)
+convert_from_openpgp_native (ctrl_t ctrl,
+			     gcry_sexp_t s_pgp,
+			     const char *passphrase,
+			     unsigned char **r_key)
 {
+  (void)ctrl;
   (void)s_pgp;
   (void)passphrase;
   (void)r_key;
diff --git a/g10/gpgv.c b/g10/gpgv.c
index b65dfa66b..2d2e43af0 100644
--- a/g10/gpgv.c
+++ b/g10/gpgv.c
@@ -462,10 +462,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+			struct keyserver_spec *keyserver,
+			unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -493,9 +496,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+		       unsigned char **fpr,size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -511,11 +519,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (const char *name,struct keyserver_spec *spec)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+		       unsigned char **fpr,size_t *fpr_len,
+		       struct keyserver_spec *keyserver,
+		       unsigned int flags)
 {
-  (void)name;
-  (void)spec;
+  (void)ctrl;
+  (void)mbox;
+  (void)fpr;
+  (void)fpr_len;
+  (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -648,13 +663,11 @@ parse_preferred_keyserver(PKT_signature *sig)
 }
 
 struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+parse_keyserver_uri (const char *string,
+		     int require_scheme)
 {
-  (void)uri;
+  (void)string;
   (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
   return NULL;
 }
 
@@ -666,11 +679,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+	     PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
diff --git a/g10/test-stubs.c b/g10/test-stubs.c
index 9b41c8929..7b9af8470 100644
--- a/g10/test-stubs.c
+++ b/g10/test-stubs.c
@@ -193,10 +193,13 @@ keyserver_any_configured (ctrl_t ctrl)
 }
 
 int
-keyserver_import_keyid (u32 *keyid, void *dummy, unsigned int flags)
+keyserver_import_keyid (ctrl_t ctrl, u32 *keyid,
+			struct keyserver_spec *keyserver,
+			unsigned int flags)
 {
+  (void)ctrl;
   (void)keyid;
-  (void)dummy;
+  (void)keyserver;
   (void)flags;
   return -1;
 }
@@ -224,9 +227,14 @@ keyserver_import_fpr_ntds (ctrl_t ctrl,
 }
 
 int
-keyserver_import_cert (const char *name)
+keyserver_import_cert (ctrl_t ctrl, const char *name, int dane_mode,
+		       unsigned char **fpr, size_t *fpr_len)
 {
+  (void)ctrl;
   (void)name;
+  (void)dane_mode;
+  (void)fpr;
+  (void)fpr_len;
   return -1;
 }
 
@@ -242,15 +250,18 @@ keyserver_import_wkd (ctrl_t ctrl, const char *name, unsigned int flags,
   return GPG_ERR_BUG;
 }
 
-int
-keyserver_import_mbox (ctrl_t ctrl, const char *mbox, unsigned char **fpr,
-                       size_t *fprlen, struct keyserver_spec *keyserver)
+gpg_error_t
+keyserver_import_mbox (ctrl_t ctrl, const char *mbox,
+		       unsigned char **fpr,size_t *fpr_len,
+		       struct keyserver_spec *keyserver,
+		       unsigned int flags)
 {
   (void)ctrl;
   (void)mbox;
   (void)fpr;
-  (void)fprlen;
+  (void)fpr_len;
   (void)keyserver;
+  (void)flags;
   return -1;
 }
 
@@ -382,13 +393,10 @@ parse_preferred_keyserver(PKT_signature *sig)
 }
 
 struct keyserver_spec *
-parse_keyserver_uri (const char *uri, int require_scheme,
-                     const char *configname, unsigned int configlineno)
+parse_keyserver_uri (const char *string, int require_scheme)
 {
-  (void)uri;
+  (void)string;
   (void)require_scheme;
-  (void)configname;
-  (void)configlineno;
   return NULL;
 }
 
@@ -400,11 +408,14 @@ free_keyserver_spec (struct keyserver_spec *keyserver)
 
 /* Stubs to avoid linking to photoid.c */
 void
-show_photos (const struct user_attribute *attrs, int count, PKT_public_key *pk)
+show_photos (ctrl_t ctrl, const struct user_attribute *attrs, int count,
+	     PKT_public_key *pk, PKT_user_id *uid)
 {
+  (void)ctrl;
   (void)attrs;
   (void)count;
   (void)pk;
+  (void)uid;
 }
 
 int
-- 
2.52.0



From wk at gnupg.org  Tue Jan  6 11:16:51 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 06 Jan 2026 11:16:51 +0100
Subject: [PATCH GnuPG 0/2] Add support for D-Trust Card 6.1/6.4
In-Reply-To: <1974271.CQOukoFCf9@localdomain> (Mario Haustein via
 Gnupg-devel's message of "Sun, 04 Jan 2026 17:06:18 +0100")
References: <1974271.CQOukoFCf9@localdomain>
Message-ID: <87h5sznizw.fsf@jacob.g10code.de>

Hi Mario,

Thanks for your work.  Please give us some days to apply your patch.
Too many other things to do in the first days of a new year.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260106/ae6a45ca/attachment.sig>

From wk at gnupg.org  Wed Jan  7 09:11:03 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 07 Jan 2026 09:11:03 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <a92da4ad-2a32-4d4b-8244-0ca15eec1734@the13thletter.info> (Marco
 Ricci via Gnupg-devel's message of "Mon,
 5 Jan 2026 20:42:44 +0100")
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
 <87ms31pnnl.fsf@jacob.g10code.de> <87ikdppmyp.fsf@jacob.g10code.de>
 <a92da4ad-2a32-4d4b-8244-0ca15eec1734@the13thletter.info>
Message-ID: <87y0m9n8q0.fsf@jacob.g10code.de>

On Mon,  5 Jan 2026 20:42, Marco Ricci said:

> I have since resolved my underlying problem (spawning gpg-agent with
> OpenSSH emulation support) directly; it turned out to be user error.

Good.

> I have multiple copies of GnuPG (via MSYS, via Git, via gpg4win)

That is actually a problem which we see more and more.  For gpg4win 5 we
have changed things so that it will be easier to install several
versions and have Kleopatra and gpgol use the intended one.

> correct, documented way to pass command-line arguments to the invocation
> of `gpg-agent`, because I wanted to debug whether I was launching

Only if you start gpg-agent by hand and not let other compinet start it
you can do:

  gpg-agent --verbose --enable-something --daemon

But gpg-agent may not already run as it would not start in this case.
It is better to let the components (or "gpgconf --launch gpg-agent")
start gpg-agent and put options into the config file.  Note that there
may also be global config file.  If you use 

  gpg-agent --debug 0

you can see the used config files:

  C:\Users\dd9jn>gpg-agent --debug 0
  gpg-agent[2928]: reading options from '[cmdline]'
  gpg-agent[2928]: reading options from 'C:/Users/dd9jn/AppData/Roaming/gnupg/common.conf'
  gpg-agent[2928]: gpg-agent running and available

in this case we have only a local common.conf.



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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260107/637d106b/attachment.sig>

From jakeginesin at gmail.com  Sat Jan 10 06:00:20 2026
From: jakeginesin at gmail.com (Jake Ginesin)
Date: Sat, 10 Jan 2026 00:00:20 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
Message-ID: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>

Hi,

libgcrypt's ECDSA signatures are malleable, as the signature verifier
accepts malforned DER-encoded signatures. We currently fail in three
scenarios:

1. Missing leading zero: per X.690 section 8.3.3, integers are two's
complement. A positive integer with high bit set requires a leading 0x00 to
avoid being interpreted as negative. libgcrypt accepts signatures missing
this byte.

2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must be
minimal. libgcrypt accepts r/s values with unnecessary leading zeros.

3. BER long-form length: per X.690 section 10.1, DER requires the definite
length form encoded in the minimum number of octets. libgcrypt accepts
BER-style long-form encoding where short-form is required.

The test vectors are available here:
https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json
(tcId 6, 8, 84, 128 are relevant for this issue)

Similar issues received CVEs in other libraries (CVE-2020-13822,
CVE-2024-42460).

Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt
harness, or discuss further.

Thanks,
Jake
https://jakegines.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260110/25a41ee9/attachment-0001.html>

From m at the13thletter.info  Tue Jan 13 09:52:12 2026
From: m at the13thletter.info (Marco Ricci)
Date: Tue, 13 Jan 2026 09:52:12 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <87y0m9n8q0.fsf@jacob.g10code.de>
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
 <87ms31pnnl.fsf@jacob.g10code.de> <87ikdppmyp.fsf@jacob.g10code.de>
 <a92da4ad-2a32-4d4b-8244-0ca15eec1734@the13thletter.info>
 <87y0m9n8q0.fsf@jacob.g10code.de>
Message-ID: <79c570d2d0404f45d863fd9436b18466@the13thletter.info>

Dear Werner,

apologies, I missed your reply last week.

Thus spoke Werner Koch:
>> correct, documented way to pass command-line arguments to the 
>> invocation
>> of `gpg-agent`, because I wanted to debug whether I was launching
> 
> Only if you start gpg-agent by hand and not let other compinet start it
> you can do:
> 
>   gpg-agent --verbose --enable-something --daemon
> 
> But gpg-agent may not already run as it would not start in this case.

Thank you.  This is the command-line I was looking for (for one-shot
uses in a separate terminal window), but couldn't find documented.  (I
was looking at the wrong place: syntactically, `--daemon` is an option,
but you're classifying and documenting it as a command.)

Cheers,
Marco


From wk at gnupg.org  Tue Jan 13 17:34:31 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Jan 2026 17:34:31 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <79c570d2d0404f45d863fd9436b18466@the13thletter.info> (Marco
 Ricci via Gnupg-devel's message of "Tue, 13 Jan 2026 09:52:12 +0100")
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
 <87ms31pnnl.fsf@jacob.g10code.de> <87ikdppmyp.fsf@jacob.g10code.de>
 <a92da4ad-2a32-4d4b-8244-0ca15eec1734@the13thletter.info>
 <87y0m9n8q0.fsf@jacob.g10code.de>
 <79c570d2d0404f45d863fd9436b18466@the13thletter.info>
Message-ID: <87v7h5ii94.fsf@jacob.g10code.de>

On Tue, 13 Jan 2026 09:52, Marco Ricci said:

> was looking at the wrong place: syntactically, `--daemon` is an option,
> but you're classifying and documenting it as a command.)

In all GnuPG components, commands and options are basically the same.
It is just that a "command" prints a slightly different error message
than an "option" and you can only use one "command".


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260113/05a26876/attachment.sig>

From lucas.mulling at suse.com  Tue Jan 13 17:54:26 2026
From: lucas.mulling at suse.com (Lucas Mulling)
Date: Tue, 13 Jan 2026 13:54:26 -0300
Subject: Can't reach dev.gnupg.org
Message-ID: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>

Hello

I can't seem to reach dev.gnupg.org, it's been in maintenance for a few
weeks now.

> GnuPG Maintenance
> We are in maintenance mode - please standby. GnuPG Mirrors.
> ID cb81d9e6a280f244aab3de7c176bb4f25a8a1d40
> Please visit our maintenance area in Hommingberg City: Maintenance Area Hommingberg City
> Don't forget to check out our recommendation of the day

Best,
Lucas M?lling


From gniibe at fsij.org  Wed Jan 14 03:08:41 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 14 Jan 2026 11:08:41 +0900
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
Message-ID: <878qe1lzdi.fsf@haruna.fsij.org>

Hello,

Jake Ginesin wrote:
> libgcrypt's ECDSA signatures are malleable, as the signature verifier
> accepts malforned DER-encoded signatures.

Thank you for your report.

Let me explain my understandings.

(1) For ECDSA (or public key crypto in general), libgcrypt uses data
format with SEXP.  It's true that SEXP is a kind of relaxed format,
which allows multiple representations.

(2) An application may use different formats (like PGP, CMS, etc.).
>From the viewpoint of libgcrypt, it's a responsibility of an application
to validate data formats/values for its own representation(s).

(3) GnuPG handles CMS by gpgsm with libksba.  Typically, it's libksba
which processes the data to be used by libgcrypt.  It accesses data, and
converts DER encoded value into SEXP so that it can be used by
libgcrypt.

> 1. Missing leading zero: per X.690 section 8.3.3, integers are two's
> complement. A positive integer with high bit set requires a leading 0x00 to
> avoid being interpreted as negative. libgcrypt accepts signatures missing
> this byte.
>
> 2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must be
> minimal. libgcrypt accepts r/s values with unnecessary leading zeros.
>
> 3. BER long-form length: per X.690 section 10.1, DER requires the definite
> length form encoded in the minimum number of octets. libgcrypt accepts
> BER-style long-form encoding where short-form is required.

Interpreting your words, I created a ticket for libksba.

	https://dev.gnupg.org/T8032

(I checked gpgsm and libksba, and I can't find the input validation of
DER encoded data/integer.)

Please add your comments to the ticket or reply this email, for further
discussion.
-- 


From gniibe at fsij.org  Wed Jan 14 07:38:12 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 14 Jan 2026 15:38:12 +0900
Subject: [PATCH libassuan] Add fixes to support IBM z/OS platform.
In-Reply-To: <CO1PR15MB50035195BBD6D625D92E212B9786A@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB50035195BBD6D625D92E212B9786A@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <875x94n1gr.fsf@haruna.fsij.org>

Sachin T wrote:
> Patch details -
> * m4/libtool.m4: use pass_all dependency checking on z/OS.
> * src/assuan-socket.c: Include sys/time.h header which defines fd_set, struct timeval.

Thank you for your report.

For the m4 change, I updated m4 (and build-aux) files from libgpg-error,
which should have same effect.

For the latter, I push the commit:

	c08091e84da7e39d0528ab9bd333818e58ab1beb

which include the header files when available.  I think that this
is better for other Operating Systems.
-- 


From wk at gnupg.org  Wed Jan 14 10:03:19 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 14 Jan 2026 10:03:19 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <DFNMA60OSHCD.HPFE023VTEIE@suse.com> (Lucas Mulling via
 Gnupg-devel's message of "Tue, 13 Jan 2026 13:54:26 -0300")
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
Message-ID: <87ldi0in1k.fsf@jacob.g10code.de>

On Tue, 13 Jan 2026 13:54, Lucas Mulling said:

> I can't seem to reach dev.gnupg.org, it's been in maintenance for a few
> weeks now.

Actually it is only in maintenance mode for networks with AI scrapers.
They are unfortunately many of them.  Those with RIPE assigned mail
addresses should not have problems, but we had to blacklist large range
of networks.  Phabricator (dev.gnupg.org) can't stand the load from
ten-thousands of scraper requests.

Please send me privately the IP ranges you are using, so that we can
whitelist them.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/89ac30e8/attachment.sig>

From shani.yosef at echo.ai  Wed Jan 14 13:28:34 2026
From: shani.yosef at echo.ai (Shani Yosef)
Date: Wed, 14 Jan 2026 14:28:34 +0200
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
Message-ID: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>

Hi Gnupg developers,

I'm submitting a fix for CVE-2025-68972, a signature verification bypass
in GnuPG 2.4.x documented at https://gpg.fail/formfeed.

*Summary*
The vulnerability allows an attacker to extend signed messages with
arbitrary data that still passes signature verification. This occurs
because commit 976e9d608 (Nov 2022) added form feed (\f) insertion for
truncated lines but did not add corresponding detection during signature
verification.

*Root Cause*
In g10/armor.c (line 784), truncated lines get a form feed character:
    afx->buffer[afx->buffer_len++] = this_truncated? '\f':'\n';

However, g10/plaintext.c's handle_plaintext() function does not check
for '\f' during hash calculation, allowing the exploit described at
https://gpg.fail/formfeed.

*The Fix*
The attached patch (CVE-2025-68972.patch) adds form feed detection in the
cleartext signature
hash calculation state machine. When '\f' is encountered, the function
logs an error and fails with GPG_ERR_BAD_SIGNATURE.


I'm happy to provide additional information, make adjustments to the
patch, or answer any questions.

Best regards,
Shani Yosef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/6123c9db/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2025-68972.patch
Type: application/octet-stream
Size: 967 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/6123c9db/attachment.obj>

From noloader at gmail.com  Wed Jan 14 15:17:22 2026
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 14 Jan 2026 09:17:22 -0500
Subject: Can't reach dev.gnupg.org
In-Reply-To: <87ldi0in1k.fsf@jacob.g10code.de>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
Message-ID: <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>

On Wed, Jan 14, 2026 at 8:46?AM Werner Koch via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> On Tue, 13 Jan 2026 13:54, Lucas Mulling said:
>
> > I can't seem to reach dev.gnupg.org, it's been in maintenance for a few
> > weeks now.
>
> Actually it is only in maintenance mode for networks with AI scrapers.
> They are unfortunately many of them.  Those with RIPE assigned mail
> addresses should not have problems, but we had to blacklist large range
> of networks.  Phabricator (dev.gnupg.org) can't stand the load from
> ten-thousands of scraper requests.

Related, some free and open source projects are using Anubis
<https://anubis.techaro.lol/> to keep most of the beggars off.  The
Anubis source code is shared on GitHub.

Another popular one is go-away.  go-away also provides its source code
via git <https://git.gammaspectra.live/git/go-away>.

There are other choices for that type of firewall, see
<https://git.gammaspectra.live/git/go-away#other-similar-projects>.

> Please send me privately the IP ranges you are using, so that we can
> whitelist them.

Jeff


From bernhard at intevation.de  Wed Jan 14 18:22:26 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 14 Jan 2026 18:22:26 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
Message-ID: <202601141822.32642.bernhard@intevation.de>

Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-devel:
> Related, some free and open source projects are using Anubis
> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
> Anubis source code is shared on GitHub.

It needs javascript enabled in the browser, AFAIK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/868cbc6f/attachment.sig>

From steffen at sdaoden.eu  Wed Jan 14 20:31:44 2026
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 14 Jan 2026 20:31:44 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <202601141822.32642.bernhard@intevation.de>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
Message-ID: <20260114193144.3PtPacgq@steffen%sdaoden.eu>

Bernhard Reiter via Gnupg-devel wrote in
 <202601141822.32642.bernhard at intevation.de>:
 |Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-devel:
 |> Related, some free and open source projects are using Anubis
 |> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
 |> Anubis source code is shared on GitHub.
 |
 |It needs javascript enabled in the browser, AFAIK.

And it seems to have user agent whitelists, even though they can
also look into HTTP headers and such to satisfy constraints.
Also it seems it can be massively misconfigured, i had lots of
trouble with FreeBSD (endless loops, aka check restarts) and parts
of .kernel.org (one accessible without check, one check always
failing), and in general i started running away when i see it.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From jakeginesin at gmail.com  Wed Jan 14 22:35:48 2026
From: jakeginesin at gmail.com (Jake Ginesin)
Date: Wed, 14 Jan 2026 16:35:48 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <878qe1lzdi.fsf@haruna.fsij.org>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <878qe1lzdi.fsf@haruna.fsij.org>
Message-ID: <CAPwwgKOsvCR3uJXSqfyhCMdrk+85exgnDyzNebs-H5W0MVUT0Q@mail.gmail.com>

Thank you for your response, and thank you for upstreaming this issue to
libksba.

May I be granted a GNU bugtracker account, such that I may participate in
the ticket thread? I would like to emphasize the security impact of this
issue, as an attacker may very trivially mutate signatures without
affecting validity. In addition to the CVEs previously mentioned,
CVE-2019-14859 and BIP-66 also report on the same issue in other libraries.

Thanks again,
Jake
https://jakegines.in

On Tue, Jan 13, 2026 at 9:08?PM NIIBE Yutaka <gniibe at fsij.org> wrote:

> Hello,
>
> Jake Ginesin wrote:
> > libgcrypt's ECDSA signatures are malleable, as the signature verifier
> > accepts malforned DER-encoded signatures.
>
> Thank you for your report.
>
> Let me explain my understandings.
>
> (1) For ECDSA (or public key crypto in general), libgcrypt uses data
> format with SEXP.  It's true that SEXP is a kind of relaxed format,
> which allows multiple representations.
>
> (2) An application may use different formats (like PGP, CMS, etc.).
> From the viewpoint of libgcrypt, it's a responsibility of an application
> to validate data formats/values for its own representation(s).
>
> (3) GnuPG handles CMS by gpgsm with libksba.  Typically, it's libksba
> which processes the data to be used by libgcrypt.  It accesses data, and
> converts DER encoded value into SEXP so that it can be used by
> libgcrypt.
>
> > 1. Missing leading zero: per X.690 section 8.3.3, integers are two's
> > complement. A positive integer with high bit set requires a leading 0x00
> to
> > avoid being interpreted as negative. libgcrypt accepts signatures missing
> > this byte.
> >
> > 2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must be
> > minimal. libgcrypt accepts r/s values with unnecessary leading zeros.
> >
> > 3. BER long-form length: per X.690 section 10.1, DER requires the
> definite
> > length form encoded in the minimum number of octets. libgcrypt accepts
> > BER-style long-form encoding where short-form is required.
>
> Interpreting your words, I created a ticket for libksba.
>
>         https://dev.gnupg.org/T8032
>
> (I checked gpgsm and libksba, and I can't find the input validation of
> DER encoded data/integer.)
>
> Please add your comments to the ticket or reply this email, for further
> discussion.
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/513d7f0b/attachment.html>

From noloader at gmail.com  Wed Jan 14 22:52:48 2026
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 14 Jan 2026 16:52:48 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
Message-ID: <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>

On Sat, Jan 10, 2026 at 12:01?AM Jake Ginesin via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> libgcrypt's ECDSA signatures are malleable, as the signature verifier accepts malforned DER-encoded signatures. We currently fail in three scenarios:

Forgive my ignorance... The DER restriction is usually in effect when
producing ASN.1 encoded objects, like when writing a public key or
producing a signature.

When consuming data, like a signature for verification, I _thought_
BER was the standard.

> 1. Missing leading zero: per X.690 section 8.3.3, integers are two's complement. A positive integer with high bit set requires a leading 0x00 to avoid being interpreted as negative. libgcrypt accepts signatures missing this byte.
>
> 2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must be minimal. libgcrypt accepts r/s values with unnecessary leading zeros.
>
> 3. BER long-form length: per X.690 section 10.1, DER requires the definite length form encoded in the minimum number of octets. libgcrypt accepts BER-style long-form encoding where short-form is required.
>
> The test vectors are available here: https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json (tcId 6, 8, 84, 128 are relevant for this issue)
>
> Similar issues received CVEs in other libraries (CVE-2020-13822, CVE-2024-42460).

They look like worthless CVEs to me.  They effectively say "this could
be bad if a program fails because of it", but they offer no
substantial proof of such a program.

> Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt harness, or discuss further.

If you can provide a non-trivial Proof of Concept for a DoS or a wild
memory write, then I would like to see it.

Jeff


From jakeginesin at gmail.com  Wed Jan 14 23:30:19 2026
From: jakeginesin at gmail.com (Jake Ginesin)
Date: Wed, 14 Jan 2026 17:30:19 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
Message-ID: <CAPwwgKMk5t=awTSiF9s3RWYMH29erORqermttytAAQXbUUdh4w@mail.gmail.com>

Hey Jeff,

Thanks for your response. For some concrete examples, it is my
understanding that non-malleability in DER parsing is important for X.509
certificate validation [1,2] and preventing transaction malleability [3].
Also, I went ahead and publicized my proof-of-concept for the first point
in this thread's initial email. [4]

Thanks,
Jake
https://jakegines.in

References:
[1] https://fstar-lang.org/papers/asn1star.pdf
[2] https://www.andrew.cmu.edu/user/bparno/papers/verdict-x509.pdf
[3] https://arxiv.org/pdf/1403.6676
[3] https://github.com/JakeGinesin/gcrypt-p256-malleability-poc

On Wed, Jan 14, 2026 at 4:53?PM Jeffrey Walton <noloader at gmail.com> wrote:

> On Sat, Jan 10, 2026 at 12:01?AM Jake Ginesin via Gnupg-devel
> <gnupg-devel at gnupg.org> wrote:
> >
> > libgcrypt's ECDSA signatures are malleable, as the signature verifier
> accepts malforned DER-encoded signatures. We currently fail in three
> scenarios:
>
> Forgive my ignorance... The DER restriction is usually in effect when
> producing ASN.1 encoded objects, like when writing a public key or
> producing a signature.
>
> When consuming data, like a signature for verification, I _thought_
> BER was the standard.
>
> > 1. Missing leading zero: per X.690 section 8.3.3, integers are two's
> complement. A positive integer with high bit set requires a leading 0x00 to
> avoid being interpreted as negative. libgcrypt accepts signatures missing
> this byte.
> >
> > 2. Extra leading zeros: per X.690 section 8.3.2, integer encoding must
> be minimal. libgcrypt accepts r/s values with unnecessary leading zeros.
> >
> > 3. BER long-form length: per X.690 section 10.1, DER requires the
> definite length form encoded in the minimum number of octets. libgcrypt
> accepts BER-style long-form encoding where short-form is required.
> >
> > The test vectors are available here:
> https://github.com/C2SP/wycheproof/blob/main/testvectors_v1/ecdsa_secp256k1_sha256_test.json
> (tcId 6, 8, 84, 128 are relevant for this issue)
> >
> > Similar issues received CVEs in other libraries (CVE-2020-13822,
> CVE-2024-42460).
>
> They look like worthless CVEs to me.  They effectively say "this could
> be bad if a program fails because of it", but they offer no
> substantial proof of such a program.
>
> > Happy to provide my proof-of-concept exploits, Wycheproof-libgcrypt
> harness, or discuss further.
>
> If you can provide a non-trivial Proof of Concept for a DoS or a wild
> memory write, then I would like to see it.
>
> Jeff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/d61d92d5/attachment-0001.html>

From sam at gentoo.org  Wed Jan 14 23:43:33 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 14 Jan 2026 22:43:33 +0000
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAPwwgKOsvCR3uJXSqfyhCMdrk+85exgnDyzNebs-H5W0MVUT0Q@mail.gmail.com>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <878qe1lzdi.fsf@haruna.fsij.org>
 <CAPwwgKOsvCR3uJXSqfyhCMdrk+85exgnDyzNebs-H5W0MVUT0Q@mail.gmail.com>
Message-ID: <87qzrrak8a.fsf@gentoo.org>

Jake Ginesin via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> Thank you for your response, and thank you for upstreaming this issue to libksba. 
>
> May I be granted a GNU bugtracker account, such that I may participate in the ticket thread? I would like to emphasize
> the security impact of this issue, as an attacker may very trivially mutate signatures without affecting validity. In
> addition to the CVEs previously mentioned, CVE-2019-14859 and BIP-66 also report on the same issue in other libraries. 

As a casual observer, is there a reason you submitted this publicly, and
not via https://gnupg.org/documentation/security.html?

I'm a bit surprised to have seen it publicly and also found it strange
someone else did something similar recently on the libgcrypt mailing list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/6ddf7bd1/attachment.sig>

From jakeginesin at gmail.com  Thu Jan 15 00:46:28 2026
From: jakeginesin at gmail.com (Jake Ginesin)
Date: Wed, 14 Jan 2026 18:46:28 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <87qzrrak8a.fsf@gentoo.org>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <878qe1lzdi.fsf@haruna.fsij.org>
 <CAPwwgKOsvCR3uJXSqfyhCMdrk+85exgnDyzNebs-H5W0MVUT0Q@mail.gmail.com>
 <87qzrrak8a.fsf@gentoo.org>
Message-ID: <CAPwwgKP6Wk3PGxdi+VDwwLtVmUkB23pZKpPX3aNdkf7i0htF_A@mail.gmail.com>

Hey Sam,

The Gnupg security webpage states, "If you found a severe security problem
and you do not want to publish it, please report it by mail to security at
gnupg.org"

In my opinion the "severe" vulnerability classification for ECDSA should be
reserved for signature forgery and private key extraction. While I judge
this issue as relevant and important to address (especially due to the
trivial exploitability), I do not see it as severe. Hence, I disclosed it
publicly. Was this the wrong decision?

Thanks,
Jake
https://jakegines.in

On Wed, Jan 14, 2026 at 5:43?PM Sam James <sam at gentoo.org> wrote:

> Jake Ginesin via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
> > Thank you for your response, and thank you for upstreaming this issue to
> libksba.
> >
> > May I be granted a GNU bugtracker account, such that I may participate
> in the ticket thread? I would like to emphasize
> > the security impact of this issue, as an attacker may very trivially
> mutate signatures without affecting validity. In
> > addition to the CVEs previously mentioned, CVE-2019-14859 and BIP-66
> also report on the same issue in other libraries.
>
> As a casual observer, is there a reason you submitted this publicly, and
> not via https://gnupg.org/documentation/security.html?
>
> I'm a bit surprised to have seen it publicly and also found it strange
> someone else did something similar recently on the libgcrypt mailing list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260114/b73c177d/attachment.html>

From jcb62281 at gmail.com  Thu Jan 15 05:57:20 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 14 Jan 2026 22:57:20 -0600
Subject: Can't reach dev.gnupg.org
In-Reply-To: <202601141822.32642.bernhard@intevation.de>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
Message-ID: <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>

On 1/14/26 11:22, Bernhard Reiter via Gnupg-devel wrote:
> Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-devel:
>> Related, some free and open source projects are using Anubis
>> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
>> Anubis source code is shared on GitHub.
> It needs javascript enabled in the browser, AFAIK.

As I understand, there is now a no-JS option (it tests whether the 
browser will follow a META redirect and present a cookie, which (AFIAK) 
every version of Mozilla supported, even before JavaScript existed).? 
Anubis also only challenges clients that claim to be "Mozilla" in the 
User-Agent string.? All others (such as "wget") simply pass.


-- Jacob




From collin.funk1 at gmail.com  Thu Jan 15 08:03:12 2026
From: collin.funk1 at gmail.com (Collin Funk)
Date: Wed, 14 Jan 2026 23:03:12 -0800
Subject: Can't reach dev.gnupg.org
In-Reply-To: <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
 <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>
Message-ID: <875x93xsr3.fsf@gmail.com>

Jacob Bachmeyer via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> On 1/14/26 11:22, Bernhard Reiter via Gnupg-devel wrote:
>> Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-devel:
>>> Related, some free and open source projects are using Anubis
>>> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
>>> Anubis source code is shared on GitHub.
>> It needs javascript enabled in the browser, AFAIK.
>
> As I understand, there is now a no-JS option (it tests whether the
> browser will follow a META redirect and present a cookie, which
> (AFIAK) every version of Mozilla supported, even before JavaScript
> existed).? Anubis also only challenges clients that claim to be
> "Mozilla" in the User-Agent string.? All others (such as "wget")
> simply pass.

The meta-refresh challenges aren't perfect. Sourceware had to use
javascript challenges for ~2 weeks at the end of December into early
January [1] [2]. At that time gnu.org was down a lot too, which is
interesting. Christmas bots?

Collin

[1] https://mastodon.social/@sourceware at fosstodon.org/115731990044151990
[2] https://mastodon.social/@sourceware at fosstodon.org/115838999997172671


From sachin.t at ibm.com  Thu Jan 15 09:56:11 2026
From: sachin.t at ibm.com (Sachin T)
Date: Thu, 15 Jan 2026 08:56:11 +0000
Subject: [PATCH libassuan] Add fixes to support IBM z/OS platform.
In-Reply-To: <875x94n1gr.fsf@haruna.fsij.org>
References: <CO1PR15MB50035195BBD6D625D92E212B9786A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <875x94n1gr.fsf@haruna.fsij.org>
Message-ID: <BY3PR15MB49960C3A63131D5E0AAA7227978CA@BY3PR15MB4996.namprd15.prod.outlook.com>

Thanks for accepting the patches.

From: NIIBE Yutaka <gniibe at fsij.org>
Date: Wednesday, 14 January 2026 at 12:08?PM
To: Sachin T <sachin.t at ibm.com>, GnuPG development <gnupg-devel at gnupg.org>
Subject: [EXTERNAL] Re: [PATCH libassuan] Add fixes to support IBM z/OS platform.

Sachin T wrote:
> Patch details -
> * m4/libtool.m4: use pass_all dependency checking on z/OS.
> * src/assuan-socket.c: Include sys/time.h header which defines fd_set, struct timeval.

Thank you for your report.

For the m4 change, I updated m4 (and build-aux) files from libgpg-error,
which should have same effect.

For the latter, I push the commit:

        c08091e84da7e39d0528ab9bd333818e58ab1beb

which include the header files when available.  I think that this
is better for other Operating Systems.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/ab004d43/attachment-0001.html>

From kloecker at kde.org  Thu Jan 15 10:03:49 2026
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 15 Jan 2026 10:03:49 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <875x93xsr3.fsf@gmail.com>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com> <875x93xsr3.fsf@gmail.com>
Message-ID: <27215732.1r3eYUQgxm@daneel>

On Donnerstag, 15. Januar 2026 08:03:12 Mitteleurop?ische Normalzeit Collin 
Funk via Gnupg-devel wrote:
> Jacob Bachmeyer via Gnupg-devel <gnupg-devel at gnupg.org> writes:
> > On 1/14/26 11:22, Bernhard Reiter via Gnupg-devel wrote:
> >> Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-
devel:
> >>> Related, some free and open source projects are using Anubis
> >>> <https://anubis.techaro.lol/> to keep most of the beggars off.  The
> >>> Anubis source code is shared on GitHub.

The KDE sysadmins had a look at many of them. The conclusion was that none of 
those modern anti-bot thingies are compatible with Phabricator.

> The meta-refresh challenges aren't perfect. Sourceware had to use
> javascript challenges for ~2 weeks at the end of December into early
> January [1] [2]. At that time gnu.org was down a lot too, which is
> interesting. Christmas bots?

Yes, there were massive attacks by bots which made the drastic measures 
necessary.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/5e5b9689/attachment.sig>

From andrewg at andrewg.com  Thu Jan 15 10:57:53 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 15 Jan 2026 09:57:53 +0000
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
In-Reply-To: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
References: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
Message-ID: <39391c53-f516-41de-ad4c-1691358caefa@andrewg.com>

Hi, Shani.

On 14/01/2026 12:28, Shani Yosef via Gnupg-devel wrote:
> The attached patch (CVE-2025-68972.patch) adds form feed detection in 
> the cleartext signature
> hash calculation state machine. When '\f' is encountered, the function
> logs an error and fails with GPG_ERR_BAD_SIGNATURE.

What if the original document had a real '\f' in it? That would mean a 
signature over it would never validate. Would it not be cleaner to stop 
truncating and adding '\f', and instead just fail on overlong lines?

A



From wk at gnupg.org  Thu Jan 15 15:09:28 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 15:09:28 +0100
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
In-Reply-To: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
 (Shani Yosef via Gnupg-devel's message of "Wed, 14 Jan 2026 14:28:34
 +0200")
References: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
Message-ID: <87jyxj7ysn.fsf@jacob.g10code.de>

Hi!

On Wed, 14 Jan 2026 14:28, Shani Yosef said:

> I'm submitting a fix for CVE-2025-68972, a signature verification bypass
> in GnuPG 2.4.x documented at https://gpg.fail/formfeed.

Please see https://gnupg.org/blog/20251226-cleartext-signatures.html
which explains why this (and most of the other reported bugs) are
invalid because this is wrong usage of a tool or social engineering.

Never ever output arbitrary data to the terminal unless you can be sure
that all control characters are filtered out (e.g. using less(1)).

> The attached patch (CVE-2025-68972.patch) adds form feed detection in the
> cleartext signature

If you do that you should also remove all other control characters as
well as Unicode control characters.


Shalom-Salam,

   Werner


p.s.
Whoever created that CVE should go to Mitre and have it invalidated.

-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/5364d005/attachment.sig>

From wk at gnupg.org  Thu Jan 15 15:11:22 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 15:11:22 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <202601141822.32642.bernhard@intevation.de> (Bernhard Reiter via
 Gnupg-devel's message of "Wed, 14 Jan 2026 18:22:26 +0100")
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
Message-ID: <87fr877yph.fsf@jacob.g10code.de>

On Wed, 14 Jan 2026 18:22, Bernhard Reiter said:

> It needs javascript enabled in the browser, AFAIK.

Which is not a problem because you need it for Phabricator anyway.  The
problem is that it seems not really easy to implement it for
Phabricator.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/52650bc5/attachment.sig>

From wk at gnupg.org  Thu Jan 15 15:16:04 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 15:16:04 +0100
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
 (Jeffrey Walton via Gnupg-devel's message of "Wed, 14 Jan 2026
 16:52:48 -0500")
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
Message-ID: <87bjiv7yhn.fsf@jacob.g10code.de>

On Wed, 14 Jan 2026 16:52, Jeffrey Walton said:

> If you can provide a non-trivial Proof of Concept for a DoS or a wild
> memory write, then I would like to see it.

Yes, this would trigger action here on our site.  Gniibe documented this 
as https://dev.gnupg.org/T8032 and I added this comment:

  Some historic integer encoding glitches from Peter Gutmann's style guide:

    Some Microsoft software will generate negative values about 50% of the time
    whenever it encodes anything as an INTEGER because it ignores the fact that
    the top bit of an integer is the sign bit (this is still occurring in
    programs released as recently as early 1998).

    Telesec:
    The certificates encode INTEGER values incorrectly by setting the high bit,
    which makes them negative values.  This is particularly problematic with RSA
    keys since they use a hardwired exponent of 3,221,225,473 (!!!) which always
    has the high bit set (0xC0000001), so all the RSA certificates have invalid
    encodings.  This was corrected in late 1999.

    The encoding of the Certificate may follow the BER rather than the DER. At
    least one implementation uses the indefinite-length encoding form for the
    SEQUENCE.

  And I don't expect that that everything is correct now. As long as we
  don't have a clear security issue here, we should not add extra
  constraints on DER or even BER parsing.



Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/fcb2db51/attachment.sig>

From wk at gnupg.org  Thu Jan 15 15:30:44 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 15:30:44 +0100
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <CAPwwgKMk5t=awTSiF9s3RWYMH29erORqermttytAAQXbUUdh4w@mail.gmail.com>
 (Jake Ginesin via Gnupg-devel's message of "Wed, 14 Jan 2026 17:30:19
 -0500")
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
 <CAPwwgKMk5t=awTSiF9s3RWYMH29erORqermttytAAQXbUUdh4w@mail.gmail.com>
Message-ID: <877btj7xt7.fsf@jacob.g10code.de>

On Wed, 14 Jan 2026 17:30, Jake Ginesin said:

> understanding that non-malleability in DER parsing is important for X.509
> certificate validation [1,2] and preventing transaction malleability [3].

The first paper is on formal verifification of parsers and I don't see a
practical application here.  In particuilar because ASN.1 has in the
real world never be used as it was designed for.  It is used for data
format description and that does work okayish.  The encoding was anyway
an afterthought and there are limitations when using DER as an encoding:
For example you can only use definite lengths for signed data which in
turn forbids the use of standard tools based stream processing.

> Also, I went ahead and publicized my proof-of-concept for the first point
> in this thread's initial email. [4]

Which is the reason that DER encoded signatures are not used in this
simplified way.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/12aea427/attachment.sig>

From wk at gnupg.org  Thu Jan 15 15:35:11 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 15:35:11 +0100
Subject: Undocumented novel Ed448 point encoding breaks interoperability
In-Reply-To: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> (Andrew
 Gallagher via Gnupg-devel's message of "Mon, 5 Jan 2026 13:55:36
 +0000")
References: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com>
Message-ID: <8734477xls.fsf@jacob.g10code.de>

On Mon,  5 Jan 2026 13:55, Andrew Gallagher said:

> Ed25519 follows the above spec, but Ed448 does not. Is this an error
> in the specification or an error in the implementation?

Yes, that is an error in the specs.  When I edited LibrePGP I included
most of the SOS specification clarifications Niibe-san once proposed to
the OpenPGP DT.  They were unfortunately rejected or got lost by that
major last rewrite of rfc4880bis.

I will correct LibrePGP for ED448 so that it matches actual use.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/c63890d8/attachment.sig>

From shani.yosef at echo.ai  Thu Jan 15 16:09:10 2026
From: shani.yosef at echo.ai (Shani Yosef)
Date: Thu, 15 Jan 2026 17:09:10 +0200
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
In-Reply-To: <87jyxj7ysn.fsf@jacob.g10code.de>
References: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
 <87jyxj7ysn.fsf@jacob.g10code.de>
Message-ID: <CAPn3GU0_vvN9YaWMafst8Hb3efaixbCjS+x2zvvf2mCZstSWfQ@mail.gmail.com>

Hi Werner,

Thank you for the clarification!
I want to say that I didn't open this CVE, I only came across it and looked
at the code. If you say it should be
disputed, I'll follow your guidance on that.

However, since I was already looking at the code, I noticed this comment
from commit 976e9d608
that I wanted to ask about:
* To make sure that a truncated line triggers a bad
* signature error we replace a removed LF by a FF or
* append a FF. Right, this is a hack but better than a
* global variable and way easier than to introduce a new
* control packet or insert a line like "[truncated]\n"
* into the filter output.

The code inserts '\f' when lines are truncated, but I didn't
find where '\f' is detected during verification to trigger the "bad
signature
error" mentioned in the comment.

Is this intentionally not implemented, or is there something that I'm
missing?

Shalom-Salam,
Shani

On Thu, 15 Jan 2026 at 16:05, Werner Koch <wk at gnupg.org> wrote:

> Hi!
>
> On Wed, 14 Jan 2026 14:28, Shani Yosef said:
>
> > I'm submitting a fix for CVE-2025-68972, a signature verification bypass
> > in GnuPG 2.4.x documented at https://gpg.fail/formfeed.
>
> Please see https://gnupg.org/blog/20251226-cleartext-signatures.html
> which explains why this (and most of the other reported bugs) are
> invalid because this is wrong usage of a tool or social engineering.
>
> Never ever output arbitrary data to the terminal unless you can be sure
> that all control characters are filtered out (e.g. using less(1)).
>
> > The attached patch (CVE-2025-68972.patch) adds form feed detection in the
> > cleartext signature
>
> If you do that you should also remove all other control characters as
> well as Unicode control characters.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> p.s.
> Whoever created that CVE should go to Mitre and have it invalidated.
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/09243b1d/attachment-0001.html>

From wk at gnupg.org  Thu Jan 15 17:11:28 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Jan 2026 17:11:28 +0100
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
In-Reply-To: <CAPn3GU0_vvN9YaWMafst8Hb3efaixbCjS+x2zvvf2mCZstSWfQ@mail.gmail.com>
 (Shani Yosef via Gnupg-devel's message of "Thu, 15 Jan 2026 17:09:10
 +0200")
References: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
 <87jyxj7ysn.fsf@jacob.g10code.de>
 <CAPn3GU0_vvN9YaWMafst8Hb3efaixbCjS+x2zvvf2mCZstSWfQ@mail.gmail.com>
Message-ID: <87qzrq7t5b.fsf@jacob.g10code.de>

On Thu, 15 Jan 2026 17:09, Shani Yosef said:

> The code inserts '\f' when lines are truncated, but I didn't
> find where '\f' is detected during verification to trigger the "bad
> signature

Well, if the truncated stuff is part of the signed text the \f chnages
the signed text and thus you will get a bad signature.  If it was not
part of the signed text you would anyway not see it in the file created
with --output.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260115/ae1da542/attachment.sig>

From steffen at sdaoden.eu  Thu Jan 15 19:07:13 2026
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 15 Jan 2026 19:07:13 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
 <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>
Message-ID: <20260115180713.83Dhz6c7@steffen%sdaoden.eu>

Jacob Bachmeyer via Gnupg-devel wrote in
 <4c31b086-e349-4ad2-9474-a16f647772e7 at gmail.com>:
 |On 1/14/26 11:22, Bernhard Reiter via Gnupg-devel wrote:
 |> Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-dev\
 |> el:
 |>> Related, some free and open source projects are using Anubis
 |>> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
 |>> Anubis source code is shared on GitHub.
 |> It needs javascript enabled in the browser, AFAIK.
 |
 |As I understand, there is now a no-JS option (it tests whether the 
 |browser will follow a META redirect and present a cookie, which (AFIAK) 
 |every version of Mozilla supported, even before JavaScript existed).? 
 |Anubis also only challenges clients that claim to be "Mozilla" in the 
 |User-Agent string.? All others (such as "wget") simply pass.

That is utter nonsense.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From steffen at sdaoden.eu  Thu Jan 15 19:29:00 2026
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 15 Jan 2026 19:29:00 +0100
Subject: Can't reach dev.gnupg.org
In-Reply-To: <20260115180713.83Dhz6c7@steffen%sdaoden.eu>
References: <DFNMA60OSHCD.HPFE023VTEIE@suse.com>
 <87ldi0in1k.fsf@jacob.g10code.de>
 <CAH8yC8kwHnchB4=dXb5DvecQscmFetn=yyuStTzJXG8dqjFwFw@mail.gmail.com>
 <202601141822.32642.bernhard@intevation.de>
 <4c31b086-e349-4ad2-9474-a16f647772e7@gmail.com>
 <20260115180713.83Dhz6c7@steffen%sdaoden.eu>
Message-ID: <20260115182900.cegiT7aM@steffen%sdaoden.eu>

Steffen Nurpmeso wrote in
 <20260115180713.83Dhz6c7 at steffen%sdaoden.eu>:
 |Jacob Bachmeyer via Gnupg-devel wrote in
 | <4c31b086-e349-4ad2-9474-a16f647772e7 at gmail.com>:
 ||On 1/14/26 11:22, Bernhard Reiter via Gnupg-devel wrote:
 ||> Am Mittwoch 14 Januar 2026 15:17:22 schrieb Jeffrey Walton via Gnupg-dev\
 ||> \
 ||> el:
 ||>> Related, some free and open source projects are using Anubis
 ||>> <https://anubis.techaro.lol/> to keep most of the beggars off. ?The
 ||>> Anubis source code is shared on GitHub.
 ||> It needs javascript enabled in the browser, AFAIK.
 ||
 ||As I understand, there is now a no-JS option (it tests whether the 
 ||browser will follow a META redirect and present a cookie, which (AFIAK) 
 ||every version of Mozilla supported, even before JavaScript existed).? 
 ||Anubis also only challenges clients that claim to be "Mozilla" in the 
 ||User-Agent string.? All others (such as "wget") simply pass.
 |
 |That is utter nonsense.

Unfortunately, that is to say!

For example the wonderful people behind .repo.or.cz just
implemented a special user agent bypass so that packagers can
download balls again; just last week, i have not updated the port
again, so i have not tried it in practice.  However the
"--user-agent=lynx" "bypass" that worked for a month stopped
working last week.  So..

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From jakeginesin at gmail.com  Fri Jan 16 08:25:37 2026
From: jakeginesin at gmail.com (Jake Ginesin)
Date: Fri, 16 Jan 2026 02:25:37 -0500
Subject: libgcrypt P256 signature malleability via weak DER enforcement
In-Reply-To: <877btj7xt7.fsf@jacob.g10code.de>
References: <CAPwwgKPyoMKqeuYgH+CBc6_51mJK1bJpnQ0OBuvVoGoYMBy_TQ@mail.gmail.com>
 <CAH8yC8mKhRUGQe_AUXrk9VCmckAxkROZF4LYUAy0kAupvoZv_w@mail.gmail.com>
 <CAPwwgKMk5t=awTSiF9s3RWYMH29erORqermttytAAQXbUUdh4w@mail.gmail.com>
 <877btj7xt7.fsf@jacob.g10code.de>
Message-ID: <CAPwwgKOrau02k3BQnfT5yEfa8uD1PuYmF7cgQTEA_0M5wrg-5Q@mail.gmail.com>

> And I don't expect that that everything is correct now. As long as we
> don't have a clear security issue here, we should not add extra
> constraints on DER or even BER parsing.

I went ahead and produced a proof-of-concept exploit for some important
downstream software using the acceptance of non-canonical DER ECDSA
encodings. Now, I believe this conversation should be transitioned to
security at gnupg.org. I will follow up there with specifics in the coming
days.

Thanks,
Jake
https://jakegines.in


On Thu, Jan 15, 2026 at 9:27?AM Werner Koch <wk at gnupg.org> wrote:

> On Wed, 14 Jan 2026 17:30, Jake Ginesin said:
>
> > understanding that non-malleability in DER parsing is important for X.509
> > certificate validation [1,2] and preventing transaction malleability [3].
>
> The first paper is on formal verifification of parsers and I don't see a
> practical application here.  In particuilar because ASN.1 has in the
> real world never be used as it was designed for.  It is used for data
> format description and that does work okayish.  The encoding was anyway
> an afterthought and there are limitations when using DER as an encoding:
> For example you can only use definite lengths for signed data which in
> turn forbids the use of standard tools based stream processing.
>
> > Also, I went ahead and publicized my proof-of-concept for the first point
> > in this thread's initial email. [4]
>
> Which is the reason that DER encoded signatures are not used in this
> simplified way.
>
>
> Salam-Shalom,
>
>    Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260116/c0e46dfe/attachment.html>

From shani.yosef at echo.ai  Sun Jan 18 13:42:47 2026
From: shani.yosef at echo.ai (Shani Yosef)
Date: Sun, 18 Jan 2026 14:42:47 +0200
Subject: [PATCH] Fix CVE-2025-68972: Form feed detection in cleartext
 signatures
In-Reply-To: <87qzrq7t5b.fsf@jacob.g10code.de>
References: <CAPn3GU1mhJVMxWPFeLrE0zA1g_N8v=1=m-K=oBqGBJx3EO9Z7g@mail.gmail.com>
 <87jyxj7ysn.fsf@jacob.g10code.de>
 <CAPn3GU0_vvN9YaWMafst8Hb3efaixbCjS+x2zvvf2mCZstSWfQ@mail.gmail.com>
 <87qzrq7t5b.fsf@jacob.g10code.de>
Message-ID: <CAPn3GU0uVQHv9YpuGBjL7awJcxzo40AvO2ssdprHNZo9viRW4g@mail.gmail.com>

Hi Werner,

Thanks for the clarification.

You mentioned whoever created it should invalidate. Since you're
the maintainer, it makes the most sense for you to dispute it directly
(https://cveform.mitre.org). Your dispute would carry the most weight.

Shalom-Salam,
Shani

On Thu, 15 Jan 2026 at 18:07, Werner Koch <wk at gnupg.org> wrote:

> On Thu, 15 Jan 2026 17:09, Shani Yosef said:
>
> > The code inserts '\f' when lines are truncated, but I didn't
> > find where '\f' is detected during verification to trigger the "bad
> > signature
>
> Well, if the truncated stuff is part of the signed text the \f chnages
> the signed text and thus you will get a bad signature.  If it was not
> part of the signed text you would anyway not see it in the file created
> with --output.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260118/474e0b3d/attachment.html>

From bjk at luxsci.net  Tue Jan 20 07:31:21 2026
From: bjk at luxsci.net (Ben Kibbey)
Date: Mon, 19 Jan 2026 22:31:21 -0800
Subject: primary key expiration and subkeys
Message-ID: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>

Hello all,

Is it normal behavior to add a subkey whose expiration is after a
primary key only to have the subkey be flagged as expired after the
primary key expires? If so, it may be good to issue a warning during
--edit-key that a subkey expiration is later than the primary since one
would have to change the expiration of both the primary and subkeys to
make use of them.

Thanks,

-- 
Ben Kibbey


From bernhard at intevation.de  Thu Jan 22 15:46:24 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 22 Jan 2026 15:46:24 +0100
Subject: primary key expiration and subkeys
In-Reply-To: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>
References: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>
Message-ID: <202601221546.36238.bernhard@intevation.de>

Hello Ben,

Am Dienstag 20 Januar 2026 07:31:21 schrieb Ben Kibbey:
> Is it normal behavior to add a subkey whose expiration is after a
> primary key

not that I have heard of it. (Which probably is the reason why you haven't 
gotten many replies, just because who would know if people do that.)

> only to have the subkey be flagged as expired after the 
> primary key expires? 

On first thought a message like this seems okay,
because what would a subkey do if the main key has expired?

> If so, it may be good to issue a warning during 
> --edit-key that a subkey expiration is later than the primary since one
> would have to change the expiration of both the primary and subkeys to
> make use of them.

--edit-key is a low level operation, I wonder what expert GUIs like Kleopatra 
would allow. And if it is worth the effort to add a warning here.

Regards,
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260122/a4cd85b9/attachment-0001.sig>

From gdt at lexort.com  Thu Jan 22 15:56:11 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 22 Jan 2026 09:56:11 -0500
Subject: primary key expiration and subkeys
In-Reply-To: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>
 (Ben Kibbey's message of "Mon, 19 Jan 2026 22:31:21 -0800")
References: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>
Message-ID: <rmi1pjh7l2s.fsf@s1.lexort.com>

Ben Kibbey <bjk at luxsci.net> writes:

> Is it normal behavior to add a subkey whose expiration is after a
> primary key only to have the subkey be flagged as expired after the
> primary key expires? If so, it may be good to issue a warning during
> --edit-key that a subkey expiration is later than the primary since one
> would have to change the expiration of both the primary and subkeys to
> make use of them.

Functionally a subkey is signed by the primary key, sort of like chained
certificates in pkix.   So while the subkey might not be expired, it
can't be validated.

Agreed that a warning is in order.


From kloecker at kde.org  Thu Jan 22 18:56:35 2026
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 22 Jan 2026 18:56:35 +0100
Subject: primary key expiration and subkeys
In-Reply-To: <202601221546.36238.bernhard@intevation.de>
References: <1768890683-1545451.76522719.f60K6VLhU1130010@rs6161.luxsci.com>
 <202601221546.36238.bernhard@intevation.de>
Message-ID: <5752152.rdbgypaU67@daneel>

On Donnerstag, 22. Januar 2026 15:46:24 Mitteleurop?ische Normalzeit Bernhard 
Reiter via Gnupg-devel wrote:
> Am Dienstag 20 Januar 2026 07:31:21 schrieb Ben Kibbey:
> > Is it normal behavior to add a subkey whose expiration is after a
> > primary key

I don't think that this makes any sense because such a subkey wouldn't be 
usable after the expiration of the primary key. The usual case is to set no 
expiration for a new subkey so that the subkey expires together with the 
primary key. The alternative is to add a subkey with an expiration (long) 
before the primary key because one wants to rotate the subkey but one wants to 
keep the primary key for a longer period of time.

> > If so, it may be good to issue a warning during
> > --edit-key that a subkey expiration is later than the primary since one
> > would have to change the expiration of both the primary and subkeys to
> > make use of them.
> 
> --edit-key is a low level operation, I wonder what expert GUIs like
> Kleopatra would allow. And if it is worth the effort to add a warning here.

Kleopatra doesn't let you specify an expiration past the (current) expiration 
of the primary key when you add a new subkey. Of course, you can change the 
expiration of the primary key to an earlier date after adding the new subkey 
and explicitly tell Kleopatra not to set the expiration of the subkeys to the 
same date. Kleopatra won't try to prevent you from shooting yourself in the 
foot if you really insist on doing so.

Regarding gpg I don't think any warning is necessary. If you use a powerful 
tool like gpg then you better know what you are doing. Moreover, a subkey 
which expires after the primary key won't do any harm. If you want to continue 
using the subkey then you can simply extend the lifetime of the primary key.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260122/8870af6b/attachment.sig>

From collin.funk1 at gmail.com  Sat Jan 24 06:42:57 2026
From: collin.funk1 at gmail.com (Collin Funk)
Date: Fri, 23 Jan 2026 21:42:57 -0800
Subject: [PATCH] Fix build with libassuan 2.
Message-ID: <520ceff4a913251a37bb44349fbdecc3b1c3e1c6.1769233137.git.collin.funk1@gmail.com>

On a system with libassuan 2, I see the following:

    $ ../configure --enable-maintainer-mode && make
    [...]
    libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I../conf -I/usr/include/libassuan2 -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -W -Wextra -Wbad-function-cast -Wwrite-strings -Wdeclaration-after-statement -Wformat -Wformat-security -Wpointer-arith -MT assuan-support.lo -MD -MP -MF .deps/assuan-support.Tpo -c ../../src/assuan-support.c  -fPIC -DPIC -o .libs/assuan-support.o
    In file included from ../../src/assuan-support.c:44:
    ../../src/priv-io.h:97:41: error: unknown type name 'assuan_pid_t'; did you mean 'assuan_fd_t'?
       97 |                      void *atforkvalue, assuan_pid_t *r_pid);
          |                                         ^~~~~~~~~~~~
          |                                         assuan_fd_t
    [...]

This patch fixes it.

-- 8< --

* src/assuan-support.c: Include util.h for the assuan_pid_t definition.

--

Fixes-commit: 77b9e1de7d7614e8e7eb79f507a1de292efb30a7
Signed-off-by: Collin Funk <collin.funk1 at gmail.com>
---
 src/assuan-support.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/assuan-support.c b/src/assuan-support.c
index 8fb45c53..86e9b562 100644
--- a/src/assuan-support.c
+++ b/src/assuan-support.c
@@ -38,6 +38,7 @@
 #include <sys/wait.h>
 #endif
 
+#include "util.h"
 #include "assuan.h"
 
 #include "gpgme.h"
-- 
2.52.0



From wk at gnupg.org  Tue Jan 27 17:49:42 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jan 2026 17:49:42 +0100
Subject: [Announce] GnuPG and Gpg4win Security Advisory (T8044)
Message-ID: <877bt30zmh.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.5.17.  This version fixes a *critical security bug* in
versions 2.5.13 to 2.5.16.  We also released a new Gpg4win version and
updated Debian packages.


Impact
======

These versions are affected:

 - GnuPG 2.5.16          (released 2025-12-30)
 - GnuPG 2.5.15          (released 2025-12-29)
 - GnuPG 2.5.14          (released 2025-11-19)
 - GnuPG 2.5.13          (released 2025-10-22)
 - Gpg4win 5.0.0         (released 2026-01-14)
 - Gpg4win 5.0.0-beta479 (released 2026-01-02)
 - Gpg4win 5.0.0-beta476 (released 2025-12-22)
 - Gpg4win 5.0.0-beta395 (released 2025-10-22)

All other versions are not affected.

A crafted CMS (S/MIME) EnvelopedData message carrying an oversized
wrapped session key can cause a stack buffer overflow in gpg-agent
during the PKDECRYPT--kem=CMS handling.  This can easily be used for a
DoS but, worse, the memory corruption can very likley also be used to
mount a remote code execution attack.  The bug was introduced while
changing an internal API to the FIPS required KEM API.

A CVE-id has not been assigned.  We track this bug as T8044 under
https://dev.gnupg.org/T8044.  This vulnerability was discovered by:
OpenAI Security Research.  Their report was received on 2026-01-18;
fixed versions released 2026-01-27.


Solution
========

If an affected GnuPG version is used please update ASAP to the new
version 2.5.17.

If an affected version of Gpg4win is used please update ASAP to the new
version 5.0.1.

If an immediate update is not possible please remove the gpgsm or
gpgsm.exe binary; this way the bug can't be remotely triggered.



Noteworthy changes in version 2.5.17 (2026-01-27)
=================================================
         [compared to version 2.5.16]

  * agent: Fix stack buffer overflow when using gpgsm and KEM.  This
    was introduced with 2.5.13; see above.  [T8044]

  * tpm: Fix possible buffer overflow in PKDECRYPT.  [T8045]

  * gpg: Fix possible NULL-deref with overlong signature packets. [T8049]

  * gpg: New export-option "keep-expired-subkeys".  [T7990]

  * gpgsm: Make multiple search patterns work with keyboxd.  [T8026]

  * agent: Add accelerator keys for "Wrong" and "Correct".  [T8055]

  * dirmngr: Help detection of bad keyserver configurations.  [T7730]

  Release-info: https://dev.gnupg.org/T7996



Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary file server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.17.tar.bz2 (8113k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.17.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.17_20260127.exe (5573k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.17_20260127.exe.sig

The source used to build this installer for 64-bit Windows is available as

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260127.tar.xz (15M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260127.tar.xz.sig

 This source tarball may also be used to download all required libraries
 at once to build a Unix version on any modern system.  See the included
 README.


Debian Packages
===============

We also provide new Debian style packages for a couple of Debian
variants.  See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu
to switch to other distros/releases.  It may take a view hours before
the new packages show up.  If you encounter other packaging problems
please report them to the gnupg-devel mailing list.


Windows Installer
=================

A new version of Gpg4win (5.0.1), our full featured Windows installer,
including this version of GnuPG, the Kleopatra GUI, and a PDF reader has
also been released.  Head over to https://gpg4win.org/


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.5.17.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.17.tar.bz2.sig gnupg-2.5.17.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.5.17.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.17.tar.bz2

   and check that the output matches the next line:

ee0bc59eadf258b6d92131911b5dca6cabc89419  gnupg-2.5.17.tar.bz2
8826ff58e245c9700391fefff34afe775300e7cd  gnupg-w32-2.5.17_20260127.tar.xz
31ac31fe8f5b4f3e3ae8e5e6a70c967a59f66e63  gnupg-w32-2.5.17_20260127.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish,
Portuguese, Russian, Swedish, Turkish, and Ukrainian being almost
completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

If you are using cleartext signatures in your application please read
https://gnupg.org/blog/20251226-cleartext-signatures.html .

In case of build problems specific to this release please first check
https://dev.gnupg.org/T7996 for updated information.  We are sorry that
due to ongoing DoS on this service, you may end up at a "is under
maintenance page".

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  A team of full-time employed
developers and contractors are working exclusively on GnuPG and related
software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win.

Fortunately, and this is still not common with free software, we have
established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helped with donations.

*Thank you all*

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

* List of Release Signing Keys:
  To guarantee that a downloaded GnuPG version has not been tampered by
  malicious entities we provide signature files for all tarballs and
  binary versions.  The keys are also signed by the long term keys of
  their respective owners.  Current releases are signed by one or more
  of these four keys:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)

    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)

    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)

    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

  The keys are available at https://gnupg.org/signature_key.html and in
  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
  Note that this mail has been signed by a different key.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
  GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260127/f7462fbf/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From marian.kechlibar at circletech.net  Tue Jan 27 17:37:00 2026
From: marian.kechlibar at circletech.net (Marian Kechlibar)
Date: Tue, 27 Jan 2026 17:37:00 +0100
Subject: Importing LibrePGP PQC secret keys in unattended mode
Message-ID: <b1c09286-fa44-4f55-8c7d-2aff82fb5c0a@circletech.net>

Hello,

with GnuPG 2.5.16 and libgcrypt 11.1.2 on Windows (Gpg4Win 5.0.0), I ran 
into an issue when importing PQC secret keys into a keyring without 
human interaction like this:

gpg --batch --yes --pinentry-mode loopback --passphrase "pass" --import 
(asc file name)

The secret key gets parsed, but not imported, and there is an IPC 
parameter complaint in stderr.

Gpg-agent log set to "guru" shows the following error:

2026-01-27 17:13:15 gpg-agent[16212] command 'IMPORT_KEY' failed: Chyba 
parametru IPC
2026-01-27 17:13:15 gpg-agent[16212] DBG: chan_0x00000000000002c0 -> ERR 
67109144 Chyba parametru IPC <GPG agent> - "--unattended" may only be 
used with OpenPGP keys

"Chyba parametru" means "Parameter error" in Czech.

This happens with both protected and unprotected (empty password) PQC 
keys, but it never happens with RSA or ECC keys.

Is this still work in progress?

(My use case: I want to run some automatic tests with separate homedirs, 
and I want to import all the test keys at their start, then 
decrypt/encrypt data using them.)

Best regards

Marian Kechlibar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260127/03a960e2/attachment-0001.sig>

From kloecker at kde.org  Tue Jan 27 19:15:24 2026
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Tue, 27 Jan 2026 19:15:24 +0100
Subject: Importing LibrePGP PQC secret keys in unattended mode
In-Reply-To: <b1c09286-fa44-4f55-8c7d-2aff82fb5c0a@circletech.net>
References: <b1c09286-fa44-4f55-8c7d-2aff82fb5c0a@circletech.net>
Message-ID: <3171326.vuYhMxLoTh@daneel>

On Dienstag, 27. Januar 2026 17:37:00 Mitteleurop?ische Normalzeit Marian 
Kechlibar wrote:
> Hello,
> 
> with GnuPG 2.5.16 and libgcrypt 11.1.2 on Windows (Gpg4Win 5.0.0), I ran 
> into an issue when importing PQC secret keys into a keyring without 
> human interaction like this:
> 
> gpg --batch --yes --pinentry-mode loopback --passphrase "pass" --import 
> (asc file name)
> 
> The secret key gets parsed, but not imported, and there is an IPC 
> parameter complaint in stderr.

This issue is tracked at https://dev.gnupg.org/T8029 .

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260127/25ef0a76/attachment.sig>

From gniibe at fsij.org  Wed Jan 28 06:17:30 2026
From: gniibe at fsij.org (Niibe Yutaka)
Date: Wed, 28 Jan 2026 14:17:30 +0900
Subject: [PATCH] Fix build with libassuan 2.
In-Reply-To: <520ceff4a913251a37bb44349fbdecc3b1c3e1c6.1769233137.git.collin.funk1@gmail.com>
References: <520ceff4a913251a37bb44349fbdecc3b1c3e1c6.1769233137.git.collin.funk1@gmail.com>
Message-ID: <87o6me71ud.fsf@jumper.gniibe.org>

Hello,

Collin Funk <collin.funk1 at gmail.com> wrote:
> * src/assuan-support.c: Include util.h for the assuan_pid_t definition.

Thank you for the patch to GPGME.  Applied and pushed (tested with
libassuan 2).
-- 


From marian.kechlibar at circletech.net  Wed Jan 28 09:26:56 2026
From: marian.kechlibar at circletech.net (Marian Kechlibar)
Date: Wed, 28 Jan 2026 09:26:56 +0100
Subject: Importing LibrePGP PQC secret keys in unattended mode
In-Reply-To: <3171326.vuYhMxLoTh@daneel>
References: <3171326.vuYhMxLoTh@daneel>
Message-ID: <87d9fe56-8150-4dc8-8975-563843439c58@circletech.net>

Hello,

I can see you already proposed a short fix. Any chance of this fix 
getting into 2.5.18?

It would help my workflow a lot.

Best regards

Marian Kechlibar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/9057c26a/attachment.sig>

From sam at gentoo.org  Wed Jan 28 13:35:01 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:01 +0000
Subject: [PATCH GnuPG 1/7] common: fix -Wdiscarded-qualifiers
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <67d3ee9854d36c4784eeb5a26882b27135d02cdc.1769603707.git.sam@gentoo.org>

* agent/command.c (cmd_havekey): Constify where possible.
(cmd_genkey): Ditto.
(cmd_get_passphrase): Ditto.
(cmd_passwd): Ditto.
(cmd_export_key): Ditto.
* common/server-help.c (option_value): Constify where possible.
* common/server-help.h (option_value): Ditto.
* common/stringhelp.c (make_dirname): Ditto.
(split_fields): Ditto.
(split_fields_colon): Ditto.
* dirmngr/dirmngr.c (handle_connections): Constify where possible.
* g10/misc.c (optlen): Constify where possible.
* g10/tofu.c (ask_about_binding): Ditto.
* sm/gpgsm.c (run_protect_tool): Constify where possible.
* tests/asschk.c (main): Constify where possible.
* tests/openpgp/fake-pinentry.c (option_value): Constify where possible.
(parse_pinentry_user_data): Ditto.
* tools/gpgconf.c (query_swdb): Constify where possible.

--

glibc-2.43 with -std=gnu23/-std=c23 (default in >= GCC 15) implements
C23's const-preserving macros for stdlib functions (i.e. you pass in
a const pointer, you get one back). Fix some resulting warnings.

Signed-off-by: Sam James <sam at gentoo.org>
---
 agent/command.c               | 12 ++++++------
 common/server-help.c          |  4 ++--
 common/server-help.h          |  2 +-
 common/stringhelp.c           |  8 ++++----
 dirmngr/dirmngr.c             |  2 +-
 g10/misc.c                    |  2 +-
 g10/tofu.c                    |  2 +-
 sm/gpgsm.c                    |  4 ++--
 tests/asschk.c                |  2 +-
 tests/openpgp/fake-pinentry.c |  8 ++++----
 tools/gpgconf.c               |  2 +-
 11 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/agent/command.c b/agent/command.c
index 21c95203c..cc3f21ddc 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -663,7 +663,7 @@ cmd_havekey (assuan_context_t ctx, char *line)
   ctrl_t ctrl = assuan_get_pointer (ctx);
   gpg_error_t err;
   unsigned char grip[20];
-  char *p;
+  const char *p;
   int list_mode = 0;  /* Less than 0 for no limit.  */
   int info_mode = 0;
   int counter;
@@ -1186,7 +1186,7 @@ cmd_genkey (assuan_context_t ctx, char *line)
   if (has_option (line, "--preset"))
     flags |= GENKEY_FLAG_PRESET;
   opt_inq_passwd = has_option (line, "--inq-passwd");
-  passwd_nonce = option_value (line, "--passwd-nonce");
+  passwd_nonce = (char *) option_value (line, "--passwd-nonce");
   if (passwd_nonce)
     {
       for (pend = passwd_nonce; *pend && !spacep (pend); pend++)
@@ -2041,7 +2041,7 @@ cmd_get_passphrase (assuan_context_t ctx, char *line)
   opt_no_ask = has_option (line, "--no-ask");
   if (has_option_name (line, "--repeat"))
     {
-      p = option_value (line, "--repeat");
+      p = (char *) option_value (line, "--repeat");
       if (p)
 	opt_repeat = atoi (p);
       else
@@ -2437,7 +2437,7 @@ cmd_passwd (assuan_context_t ctx, char *line)
     return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
 
   opt_preset = has_option (line, "--preset");
-  cache_nonce = option_value (line, "--cache-nonce");
+  cache_nonce = (char *) option_value (line, "--cache-nonce");
   opt_verify = has_option (line, "--verify");
   if (cache_nonce)
     {
@@ -2454,7 +2454,7 @@ cmd_passwd (assuan_context_t ctx, char *line)
         }
     }
 
-  passwd_nonce = option_value (line, "--passwd-nonce");
+  passwd_nonce = (char *) option_value (line, "--passwd-nonce");
   if (passwd_nonce)
     {
       for (pend = passwd_nonce; *pend && !spacep (pend); pend++)
@@ -3138,7 +3138,7 @@ cmd_export_key (assuan_context_t ctx, char *line)
   if (mode1003)
     openpgp = 0;
 
-  cache_nonce = option_value (line, "--cache-nonce");
+  cache_nonce = (char *) option_value (line, "--cache-nonce");
   if (cache_nonce)
     {
       for (pend = cache_nonce; *pend && !spacep (pend); pend++)
diff --git a/common/server-help.c b/common/server-help.c
index e5a69e02d..812dcb932 100644
--- a/common/server-help.c
+++ b/common/server-help.c
@@ -164,10 +164,10 @@ get_option_value (char *line, const char *name, char **r_value)
 
 /* Return a pointer to the argument of the option with NAME.  If such
    an option is not given, NULL is returned. */
-char *
+const char *
 option_value (const char *line, const char *name)
 {
-  char *s;
+  const char *s;
   int n = strlen (name);
 
   s = strstr (line, name);
diff --git a/common/server-help.h b/common/server-help.h
index 9d2f4cfba..102b9cc9b 100644
--- a/common/server-help.h
+++ b/common/server-help.h
@@ -65,6 +65,6 @@ gpg_error_t get_option_value (char *line, const char *name, char **r_value);
 
 /* Return a pointer to the argument of the option with NAME.  If such
    an option is not given, NULL is returned. */
-char *option_value (const char *line, const char *name);
+const char *option_value (const char *line, const char *name);
 
 #endif	/* GNUPG_COMMON_SERVER_HELP_H */
diff --git a/common/stringhelp.c b/common/stringhelp.c
index 8bbc68ab1..7095b5477 100644
--- a/common/stringhelp.c
+++ b/common/stringhelp.c
@@ -375,7 +375,7 @@ make_basename(const char *filepath, const char *inputpath)
 #ifdef __riscos__
     return riscos_make_basename(filepath, inputpath);
 #else
-    char *p;
+    const char *p;
 
     (void)inputpath; /* Only required for riscos.  */
 
@@ -406,7 +406,7 @@ make_dirname(const char *filepath)
 {
     char *dirname;
     int  dirname_length;
-    char *p;
+    const char *p;
 
     if ( !(p=strrchr(filepath, '/')) )
 #ifdef HAVE_DOSISH_SYSTEM
@@ -1422,7 +1422,7 @@ int
 split_fields (char *string, const char **array, int arraysize)
 {
   int n = 0;
-  const char *p;
+  char *p;
   char *pend;
 
   for (p = string; *p == ' '; p++)
@@ -1461,7 +1461,7 @@ int
 split_fields_colon (char *string, const char **array, int arraysize)
 {
   int n = 0;
-  const char *p;
+  char *p;
   char *pend;
 
   p = string;
diff --git a/dirmngr/dirmngr.c b/dirmngr/dirmngr.c
index c3cdd56a7..a92611365 100644
--- a/dirmngr/dirmngr.c
+++ b/dirmngr/dirmngr.c
@@ -2400,7 +2400,7 @@ handle_connections (assuan_fd_t listen_fd)
     {
       /* We need to watch the directory for the file because there
        * won't be an IN_DELETE_SELF for a socket file.  */
-      char *slash = strrchr (socket_name, '/');
+      char *slash = (char *) strrchr (socket_name, '/');
       log_assert (slash && slash[1]);
       *slash = 0;
       if (inotify_add_watch (my_inotify_fd, socket_name, IN_DELETE) == -1)
diff --git a/g10/misc.c b/g10/misc.c
index 58932ed7b..addce3e63 100644
--- a/g10/misc.c
+++ b/g10/misc.c
@@ -1565,7 +1565,7 @@ argsplit(char *string)
 static size_t
 optlen(const char *s)
 {
-  char *end=strpbrk(s," =");
+  const char *end=strpbrk(s," =");
 
   if(end)
     return end-s;
diff --git a/g10/tofu.c b/g10/tofu.c
index 740ee6475..e00a1569c 100644
--- a/g10/tofu.c
+++ b/g10/tofu.c
@@ -1981,7 +1981,7 @@ ask_about_binding (ctrl_t ctrl,
         }
       else if (!response[1])
         {
-          char *choice = strchr (choices, *response);
+          const char *choice = strchr (choices, *response);
 
           if (choice)
             {
diff --git a/sm/gpgsm.c b/sm/gpgsm.c
index d1f9a59d3..0516af964 100644
--- a/sm/gpgsm.c
+++ b/sm/gpgsm.c
@@ -2514,7 +2514,7 @@ run_protect_tool (int argc, char **argv)
   (void)argv;
 #else
   const char *pgm;
-  char **av;
+  const char **av;
   int i;
 
   if (!opt.protect_tool_program || !*opt.protect_tool_program)
@@ -2529,7 +2529,7 @@ run_protect_tool (int argc, char **argv)
   for (i=1; argc; i++, argc--, argv++)
     av[i] = *argv;
   av[i] = NULL;
-  execv (pgm, av);
+  execv (pgm, (char * const *) av);
   log_error ("error executing '%s': %s\n", pgm, strerror (errno));
 #endif /*!HAVE_W32_SYSTEM*/
   gpgsm_exit (2);
diff --git a/tests/asschk.c b/tests/asschk.c
index b32f9361c..b1d1920ea 100644
--- a/tests/asschk.c
+++ b/tests/asschk.c
@@ -1037,7 +1037,7 @@ main (int argc, char **argv)
     {
       invocation_name = *argv++;
       argc--;
-      p = strrchr (invocation_name, '/');
+      p = (char *) strrchr (invocation_name, '/');
       if (p)
         invocation_name = p+1;
     }
diff --git a/tests/openpgp/fake-pinentry.c b/tests/openpgp/fake-pinentry.c
index b460a1da3..4462d1b9d 100644
--- a/tests/openpgp/fake-pinentry.c
+++ b/tests/openpgp/fake-pinentry.c
@@ -176,10 +176,10 @@ skip_options (const char *line)
 
 /* Return a pointer to the argument of the option with NAME.  If such
    an option is not given, NULL is returned. */
-char *
+const char *
 option_value (const char *line, const char *name)
 {
-  char *s;
+  const char *s;
   int n = strlen (name);
 
   s = strstr (line, name);
@@ -210,7 +210,7 @@ parse_pinentry_user_data (const char *args,
     fclose (log_stream);
   log_stream = NULL;
 
-  logfile = option_value (args, "--logfile");
+  logfile = (char *) option_value (args, "--logfile");
   if (logfile)
     {
       char *p = logfile, more;
@@ -228,7 +228,7 @@ parse_pinentry_user_data (const char *args,
         }
     }
 
-  passphrasefile = option_value (args, "--passphrasefile");
+  passphrasefile = (char *) option_value (args, "--passphrasefile");
   if (passphrasefile)
     {
       char *p = passphrasefile, more;
diff --git a/tools/gpgconf.c b/tools/gpgconf.c
index 9fcd5dfd5..40cfaf655 100644
--- a/tools/gpgconf.c
+++ b/tools/gpgconf.c
@@ -551,7 +551,7 @@ query_swdb (estream_t out, const char *name, const char *current_version)
         }
 
       /* Tokenize the name.  */
-      p = strrchr (fields[0], '_');
+      p = (char *) strrchr (fields[0], '_');
       if (!p)
         continue; /* Name w/o an underscore.  */
       *p++ = 0;
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:02 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:02 +0000
Subject: [PATCH GnuPG 2/7] common: fix -Wunused-but-set-variable
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <29b0baaa1c1c575ddfba96da2fbe20ee840aa486.1769603707.git.sam@gentoo.org>

* common/ssh-utils.c (get_fingerprint): Drop unused 'idx' in loop.

--

idx was never used other than being incremented. Found by GCC 16's
enhanced -Wunused-but-set-variable.

Signed-off-by: Sam James <sam at gentoo.org>
---
 common/ssh-utils.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/common/ssh-utils.c b/common/ssh-utils.c
index d27e2e200..9764ae68c 100644
--- a/common/ssh-utils.c
+++ b/common/ssh-utils.c
@@ -82,7 +82,6 @@ get_fingerprint (gcry_sexp_t key, int algo,
   gcry_sexp_t l2 = NULL;
   const char *s;
   char *name = NULL;
-  int idx;
   const char *elems;
   gcry_md_hd_t md = NULL;
   int blobmode = 0;
@@ -181,7 +180,7 @@ get_fingerprint (gcry_sexp_t key, int algo,
     goto leave;
 
 
-  for (idx = 0, s = elems; *s; s++, idx++)
+  for (s = elems; *s; s++)
     {
       l2 = gcry_sexp_find_token (list, s, 1);
       if (!l2)
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:06 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:06 +0000
Subject: [PATCH GnuPG 6/7] g10: fix uninit use
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <652fb3f4c332a694cf2303b8a7d9bb1d32771300.1769603707.git.sam@gentoo.org>

* g10/encrypt.c (reencrypt_to_new_recipients): Drop first
  (and uninitialized) use of 'count'.

--

In reencrypt_to_new_recipients, count isn't used in the first loop
and we later initialise it before another loop (where it is used), so
drop the first bogus use, as the increment was working w/ an uninit var
otherwise.

Found by GCC's -fanalyzer.

Signed-off-by: Sam James <sam at gentoo.org>
---
 g10/encrypt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/encrypt.c b/g10/encrypt.c
index b305ce938..19b2f7d13 100644
--- a/g10/encrypt.c
+++ b/g10/encrypt.c
@@ -1114,7 +1114,7 @@ reencrypt_to_new_recipients (ctrl_t ctrl, int armor, const char *filename,
    * recipient.  We can't do that for wildcards, though.  */
   if (!ctrl->clear_recipients)
     {
-      for (el = sesenc_list; el; el = el->next, count++)
+      for (el = sesenc_list; el; el = el->next)
         {
           if (el->u_sym)
             continue;
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:00 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:00 +0000
Subject: [PATCH GnuPG 0/7] Misc GCC -fanalyzer fixes
Message-ID: <cover.1769603707.git.sam@gentoo.org>

Prompted by Werner's comment at https://lwn.net/Articles/1056277/ as
I was wondering if GCC's -fanalyzer would fare any better.

I have some more such fixes depending on how this series goes and if they're
desired.

I've tried to restrict to changes where it seems like a general improvement
and skipped a few obvious false positives where a code change couldn't really
be justified.

Sam James (7):
  common: fix -Wdiscarded-qualifiers
  common: fix -Wunused-but-set-variable
  common: fix -Werror=analyzer-deref-before-check
  common: check strchr for null
  g10: check null in assert
  g10: fix uninit use
  g10: fix uninit use

 agent/command.c               | 12 ++++++------
 common/asshelp.c              |  3 ++-
 common/iobuf.c                |  2 +-
 common/server-help.c          |  4 ++--
 common/server-help.h          |  2 +-
 common/ssh-utils.c            |  3 +--
 common/stringhelp.c           |  8 ++++----
 dirmngr/dirmngr.c             |  2 +-
 g10/decrypt-data.c            |  2 +-
 g10/encrypt.c                 |  2 +-
 g10/keyedit.c                 |  4 ++--
 g10/misc.c                    |  2 +-
 g10/tofu.c                    |  2 +-
 sm/gpgsm.c                    |  4 ++--
 tests/asschk.c                |  2 +-
 tests/openpgp/fake-pinentry.c |  8 ++++----
 tools/gpgconf.c               |  2 +-
 17 files changed, 32 insertions(+), 32 deletions(-)

-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:05 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:05 +0000
Subject: [PATCH GnuPG 5/7] g10: check null in assert
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>

* g10/keyedit.c (keyedit_quick_revsig): Check 'keyblock' in log_assert.

--

Found by GCC's -fanalyzer.

Signed-off-by: Sam James <sam at gentoo.org>
---
 g10/keyedit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/g10/keyedit.c b/g10/keyedit.c
index 970a72027..567de4efd 100644
--- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -3306,8 +3306,8 @@ keyedit_quick_revsig (ctrl_t ctrl, const char *username, const char *sigtorev,
   err = quick_find_keyblock (ctrl, username, 0, &kdbhd, &keyblock);
   if (err)
     goto leave;
-  log_assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
-              || keyblock->pkt->pkttype == PKT_SECRET_KEY);
+  log_assert (keyblock && (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
+              || keyblock->pkt->pkttype == PKT_SECRET_KEY));
   primarypk = keyblock->pkt->pkt.public_key;
   primarykid = pk_keyid (primarypk);
 
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:03 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:03 +0000
Subject: [PATCH GnuPG 3/7] common: fix -Werror=analyzer-deref-before-check
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <46470da1242fd39478e8b9c0c17552fbf6baddeb.1769603707.git.sam@gentoo.org>

* common/iobuf.c (iobuf_get_real_fname): Check if 'a' is null earlier.

--

Check `a` before it is used in an if, because we later do a null-pointer
check in the loop which triggers a "null pointer check but too late"
warning.

The callers seem safe already but fix it to stop GCC's -fanalyzer
complaining.

Found by GCC's -fanalyzer.

Signed-off-by: Sam James <sam at gentoo.org>
---
 common/iobuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/iobuf.c b/common/iobuf.c
index 769df958d..09cedbb50 100644
--- a/common/iobuf.c
+++ b/common/iobuf.c
@@ -2768,7 +2768,7 @@ iobuf_seek (iobuf_t a, off_t newpos)
 const char *
 iobuf_get_real_fname (iobuf_t a)
 {
-  if (a->real_fname)
+  if (a && a->real_fname)
     return a->real_fname;
 
   /* the old solution */
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:07 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:07 +0000
Subject: [PATCH GnuPG 7/7] g10: fix uninit use
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <00e58c60b4f01f944b91356247931f2b2f4d2c46.1769603707.git.sam@gentoo.org>

* g10/decrypt-data.c (aead_underflow): Initialize 'err'
  to 0.

--

Just initialize to 0 and then there's no risk of using an uninit var
if we (somehow) fall through to the end label.

Found by GCC's -fanalyzer.

Signed-off-by: Sam James <sam at gentoo.org>
---
 g10/decrypt-data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g10/decrypt-data.c b/g10/decrypt-data.c
index 0f1551144..8b1469257 100644
--- a/g10/decrypt-data.c
+++ b/g10/decrypt-data.c
@@ -638,7 +638,7 @@ static gpg_error_t
 aead_underflow (decode_filter_ctx_t dfx, iobuf_t a, byte *buf, size_t *ret_len)
 {
   const size_t size = *ret_len; /* The allocated size of BUF.  */
-  gpg_error_t err;
+  gpg_error_t err = 0;
   size_t totallen = 0; /* The number of bytes to return on success or EOF.  */
   size_t off = 0;      /* The offset into the buffer.  */
   size_t len;          /* The current number of bytes in BUF+OFF.  */
-- 
2.52.0



From sam at gentoo.org  Wed Jan 28 13:35:04 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 12:35:04 +0000
Subject: [PATCH GnuPG 4/7] common: check strchr for null
In-Reply-To: <cover.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
Message-ID: <cf076e471ef2b00d867d726f880c68a1bf1e53a0.1769603707.git.sam@gentoo.org>

* common/asshelp.c (start_new_service): Check if strchr
  result is NULL.

--

We check program_args later on before use, so it's enough to just
conditionally check-then-deref-and-increment, because later on, we
won't use it otherwise.

Found by GCC's -fanalyzer.

Signed-off-by: Sam James <sam at gentoo.org>
---
 common/asshelp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/asshelp.c b/common/asshelp.c
index 82a7b11d0..b119c249c 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -486,7 +486,8 @@ start_new_service (assuan_context_t *r_ctx,
               return tmperr;
             }
           p = strchr (program, '|');
-          *p++ = 0;
+          if (p)
+              *p++ = 0;
           program_arg = p;
         }
 
-- 
2.52.0



From wk at gnupg.org  Wed Jan 28 16:08:55 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jan 2026 16:08:55 +0100
Subject: [PATCH GnuPG 4/7] common: check strchr for null
In-Reply-To: <cf076e471ef2b00d867d726f880c68a1bf1e53a0.1769603707.git.sam@gentoo.org>
 (Sam James via Gnupg-devel's message of "Wed, 28 Jan 2026 12:35:04
 +0000")
References: <cover.1769603707.git.sam@gentoo.org>
 <cf076e471ef2b00d867d726f880c68a1bf1e53a0.1769603707.git.sam@gentoo.org>
Message-ID: <878qdhzse0.fsf@jacob.g10code.de>

Hi!

Here is an example on why manual introspection is required on all static
analyzer output:

On Wed, 28 Jan 2026 12:35, Sam James said:
>            p = strchr (program, '|');
> -          *p++ = 0;
> +          if (p)
> +              *p++ = 0;

This is is something the analyzer did not got right.  This if-branch is
only entered iff program_name already contains a '|'.  program is a copy
of program_name.

A log_assert could be used but the code is short enoigh to see that this
will never be triggred.



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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/3ecf8ca3/attachment.sig>

From wk at gnupg.org  Wed Jan 28 16:13:58 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jan 2026 16:13:58 +0100
Subject: [PATCH GnuPG v2] Fix -Wlto-type-mismatch warnings [T4416]
In-Reply-To: <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>
 (Sam James via Gnupg-devel's message of "Sun, 4 Jan 2026 05:18:24
 +0000")
References: <4cc541d6db5198d5f01860b228d09f26b5692479.1767492688.git.sam@gentoo.org>
 <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>
Message-ID: <874io5zs5l.fsf@jacob.g10code.de>

Hi!

sorry for not reading your patch earlier.  Today we tried to build for
the future Ubuntu release and stumbled on the same errors.  I fixed them
without remembering your patches - sorry but thanks for your work.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/aee9e6a5/attachment.sig>

From sam at gentoo.org  Wed Jan 28 19:08:20 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 18:08:20 +0000
Subject: [PATCH GnuPG 4/7] common: check strchr for null
In-Reply-To: <878qdhzse0.fsf@jacob.g10code.de>
References: <cover.1769603707.git.sam@gentoo.org>
 <cf076e471ef2b00d867d726f880c68a1bf1e53a0.1769603707.git.sam@gentoo.org>
 <878qdhzse0.fsf@jacob.g10code.de>
Message-ID: <878qdhr4ob.fsf@gentoo.org>

Werner Koch <wk at gnupg.org> writes:

> Hi!

Hi!

>
> Here is an example on why manual introspection is required on all static
> analyzer output:
>
> On Wed, 28 Jan 2026 12:35, Sam James said:
>>            p = strchr (program, '|');
>> -          *p++ = 0;
>> +          if (p)
>> +              *p++ = 0;
>
> This is is something the analyzer did not got right.  This if-branch is
> only entered iff program_name already contains a '|'.  program is a copy
> of program_name.
>
> A log_assert could be used but the code is short enoigh to see that this
> will never be triggred.
>

Gah, yes, I'm sorry for the noise. I clearly got carried away with
that. I'll check more carefully and see if any are still worth it in
that case.

Thank you!

>
>
> Salam-Shalom,
>
>    Werner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/3bcfd2fe/attachment.sig>

From sam at gentoo.org  Wed Jan 28 19:08:41 2026
From: sam at gentoo.org (Sam James)
Date: Wed, 28 Jan 2026 18:08:41 +0000
Subject: [PATCH GnuPG v2] Fix -Wlto-type-mismatch warnings [T4416]
In-Reply-To: <874io5zs5l.fsf@jacob.g10code.de>
References: <4cc541d6db5198d5f01860b228d09f26b5692479.1767492688.git.sam@gentoo.org>
 <21e2bca92f2d95c942036a3b42f29469648a5bca.1767503904.git.sam@gentoo.org>
 <874io5zs5l.fsf@jacob.g10code.de>
Message-ID: <87zf5xpq3a.fsf@gentoo.org>

Werner Koch <wk at gnupg.org> writes:

> Hi!
>
> sorry for not reading your patch earlier.  Today we tried to build for
> the future Ubuntu release and stumbled on the same errors.  I fixed them
> without remembering your patches - sorry but thanks for your work.

No worries, it happens -- thank you for fixing it!

>
>
> Shalom-Salam,
>
>    Werner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/f17d47ac/attachment-0001.sig>

From jcb62281 at gmail.com  Thu Jan 29 03:59:48 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 28 Jan 2026 20:59:48 -0600
Subject: [PATCH GnuPG 5/7] g10: check null in assert
In-Reply-To: <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
 <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>
Message-ID: <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com>

On 1/28/26 06:35, Sam James via Gnupg-devel wrote:
> * g10/keyedit.c (keyedit_quick_revsig): Check 'keyblock' in log_assert.
>
> --
>
> Found by GCC's -fanalyzer.
>
> Signed-off-by: Sam James <sam at gentoo.org>
> ---
>   g10/keyedit.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/g10/keyedit.c b/g10/keyedit.c
> index 970a72027..567de4efd 100644
> --- a/g10/keyedit.c
> +++ b/g10/keyedit.c
> @@ -3306,8 +3306,8 @@ keyedit_quick_revsig (ctrl_t ctrl, const char *username, const char *sigtorev,
>     err = quick_find_keyblock (ctrl, username, 0, &kdbhd, &keyblock);
>     if (err)
>       goto leave;
> -  log_assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
> -              || keyblock->pkt->pkttype == PKT_SECRET_KEY);
> +  log_assert (keyblock && (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
> +              || keyblock->pkt->pkttype == PKT_SECRET_KEY));
>     primarypk = keyblock->pkt->pkt.public_key;
>     primarykid = pk_keyid (primarypk);

Minor nit:? this expression should either be split across three lines or 
the second line indented to line up after the opening paren.? As it 
stands, it is easy for a human to misread.

Alternately, is it possible for this code to be reached if keyblock is 
NULL?? Perhaps a better solution would be to change the "if (err)" to 
"if (err || !keyblock)" or the more verbose "if (err != 0 || keyblock == 
NULL)"?? (I assume that quick_find_keyblock always returns an error if 
keyblock is NULL upon return, but the analyzer does not know that.)

Some future version of GCC can optimize the "|| !keyblock" away when it 
is able to prove that "!err" implies "keyblock".? Current GCC clearly 
cannot do this.

Now that I look at this a bit more, I think we may have found another 
shortcoming in the analyzer:? does log_assert crash the program on an 
assertion failure?? Does the analyzer know that?? If not, a NULL 
keyblock would be dereferenced on the very next line, but the analyzer 
sees that it was checked and is happy... oops.


-- Jacob




From sam at gentoo.org  Thu Jan 29 05:11:16 2026
From: sam at gentoo.org (Sam James)
Date: Thu, 29 Jan 2026 04:11:16 +0000
Subject: [PATCH GnuPG 5/7] g10: check null in assert
In-Reply-To: <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com>
References: <cover.1769603707.git.sam@gentoo.org>
 <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>
 <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com>
Message-ID: <87qzr9oy6z.fsf@gentoo.org>

Jacob Bachmeyer <jcb62281 at gmail.com> writes:

> On 1/28/26 06:35, Sam James via Gnupg-devel wrote:
>> * g10/keyedit.c (keyedit_quick_revsig): Check 'keyblock' in log_assert.
>>
>> --
>>
>> Found by GCC's -fanalyzer.
>>
>> Signed-off-by: Sam James <sam at gentoo.org>
>> ---
>>   g10/keyedit.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/g10/keyedit.c b/g10/keyedit.c
>> index 970a72027..567de4efd 100644
>> --- a/g10/keyedit.c
>> +++ b/g10/keyedit.c
>> @@ -3306,8 +3306,8 @@ keyedit_quick_revsig (ctrl_t ctrl, const char *username, const char *sigtorev,
>>     err = quick_find_keyblock (ctrl, username, 0, &kdbhd, &keyblock);
>>     if (err)
>>       goto leave;
>> -  log_assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
>> -              || keyblock->pkt->pkttype == PKT_SECRET_KEY);
>> +  log_assert (keyblock && (keyblock->pkt->pkttype == PKT_PUBLIC_KEY
>> +              || keyblock->pkt->pkttype == PKT_SECRET_KEY));
>>     primarypk = keyblock->pkt->pkt.public_key;
>>     primarykid = pk_keyid (primarypk);
>
> Minor nit:? this expression should either be split across three lines
> or the second line indented to line up after the opening paren.? As it
> stands, it is easy for a human to misread.
>

ack

> Alternately, is it possible for this code to be reached if keyblock is
> NULL?? Perhaps a better solution would be to change the "if (err)" to
> "if (err || !keyblock)" or the more verbose "if (err != 0 || keyblock
> == NULL)"?? (I assume that quick_find_keyblock always returns an error
> if keyblock is NULL upon return, but the analyzer does not know that.)
>

Yes, this is a pattern I saw a few times where it doesn't understand
error-return relations, unfortunately.

It does look into q_f_k, it just isn't able to deduce that they're tied,
even though when looking at it, it seems to be fine.

In this case, adding the check inside of an asset seemed reasonable to
me to make it clear and allow further analysis, but I can understand not
agreeing with that. I wouldn't want to litter the codebase with
suppressions either.
 
> Some future version of GCC can optimize the "|| !keyblock" away when
> it is able to prove that "!err" implies "keyblock".? Current GCC
> clearly cannot do this.
>
> Now that I look at this a bit more, I think we may have found another
> shortcoming in the analyzer:?

I plan on filing some GCC bugs for any analyzer shortcomings we end up
finding so the discussion is interesting, thanks.

> does log_assert crash the program on an
> assertion failure?? Does the analyzer know that?? If not, a NULL
> keyblock would be dereferenced on the very next line, but the analyzer
> sees that it was checked and is happy... oops.

It should do, because it's defined as:

# ifdef GPGRT_HAVE_MACRO_FUNCTION
#  define log_assert(expr)                                      \
  ((expr)                                                       \
   ? (void) 0                                                   \
   : _gpgrt_log_assert (#expr, __FILE__, __LINE__, __FUNCTION__))
# else /*!GPGRT_HAVE_MACRO_FUNCTION*/
#  define log_assert(expr)                                      \
  ((expr)                                                       \
   ? (void) 0                                                   \
   : _gpgrt_log_assert (#expr, __FILE__, __LINE__, NULL))
# endif /*!GPGRT_HAVE_MACRO_FUNCTION*/

and _gpgrt_log_assert is noreturn.

>
>
> -- Jacob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260129/21340b35/attachment.sig>

From jcb62281 at gmail.com  Thu Jan 29 05:42:50 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 28 Jan 2026 22:42:50 -0600
Subject: [PATCH GnuPG 5/7] g10: check null in assert
In-Reply-To: <87qzr9oy6z.fsf@gentoo.org>
References: <cover.1769603707.git.sam@gentoo.org>
 <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>
 <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com> <87qzr9oy6z.fsf@gentoo.org>
Message-ID: <56ed1d28-eabd-49b8-b1db-be60784f0e6d@gmail.com>

On 1/28/26 22:11, Sam James wrote:
> Jacob Bachmeyer<jcb62281 at gmail.com> writes:
> [...]
>> Alternately, is it possible for this code to be reached if keyblock is
>> NULL?? Perhaps a better solution would be to change the "if (err)" to
>> "if (err || !keyblock)" or the more verbose "if (err != 0 || keyblock
>> == NULL)"?? (I assume that quick_find_keyblock always returns an error
>> if keyblock is NULL upon return, but the analyzer does not know that.)
> Yes, this is a pattern I saw a few times where it doesn't understand
> error-return relations, unfortunately.
>
> It does look into q_f_k, it just isn't able to deduce that they're tied,
> even though when looking at it, it seems to be fine.
>
> [...]
> I plan on filing some GCC bugs for any analyzer shortcomings we end up
> finding so the discussion is interesting, thanks.

I think that the analyzer being unable to recognize that "!err" implies 
keyblock is non-NULL even though it *does* look inside the 
quick_find_keyblock function is a shortcoming worth a GCC bug report 
because it results in complaints for which maintainers could 
legitimately reject patches, as there is no actual problem.


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260128/cbf30cff/attachment.html>

From wk at gnupg.org  Thu Jan 29 10:42:14 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2026 10:42:14 +0100
Subject: [PATCH GnuPG 5/7] g10: check null in assert
In-Reply-To: <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com> (Jacob Bachmeyer
 via Gnupg-devel's message of "Wed, 28 Jan 2026 20:59:48 -0600")
References: <cover.1769603707.git.sam@gentoo.org>
 <15cec20c30ff79a9478e2960224848574dcbc977.1769603707.git.sam@gentoo.org>
 <6508a464-e4db-4cfd-b0a5-b5ea1dbf1cc0@gmail.com>
Message-ID: <87qzr8ycuh.fsf@jacob.g10code.de>

On Wed, 28 Jan 2026 20:59, Jacob Bachmeyer said:

> NULL?? Perhaps a better solution would be to change the "if (err)" to
> "if (err || !keyblock)" or the more verbose "if (err != 0 || keyblock

In this case you may have ERR == 0 and need to make sure that ERR is
set.  

> shortcoming in the analyzer:? does log_assert crash the program on an
> assertion failure?? Does the analyzer know that?? If not, a NULL

This is the macro:

  # ifdef GPGRT_HAVE_MACRO_FUNCTION
  #  define log_assert(expr)                                      \
    ((expr)                                                       \
     ? (void) 0                                                   \
     : _gpgrt_log_assert (#expr, __FILE__, __LINE__, __FUNCTION__))

and this is the prototype:
  
  void _gpgrt_log_assert (const char *expr, const char *file, int line,
                          const char *func) GPGRT_ATTR_NORETURN;
  
with:

/* The noreturn attribute.  */
#if _GPG_ERR_GCC_VERSION >= 20500
# define GPGRT_ATTR_NORETURN   __attribute__ ((__noreturn__))
#else
# define GPGRT_ATTR_NORETURN
#endif

So gcc should be able to know this.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260129/a3bc3d28/attachment.sig>

From wk at gnupg.org  Thu Jan 29 14:09:43 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Jan 2026 14:09:43 +0100
Subject: [Announce] Libgcrypt 1.12.0 released
Message-ID: <87ecn8y38o.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of Libgcrypt version 1.12.0.

This release starts a new stable branch of Libgcrypt with full API and
ABI compatibility to the 1.11 series.  Since the last major release
Jussi Kivilinna put again a lot of work into speeding up the algorithms
for modern CPUs.  Niibe-san implemented new APIs and algorithms and
adjusted the interface for new FIPS requirements.  See below for a list
of improvements and new features in 1.12.

Libgcrypt is a general purpose library of cryptographic building blocks.
It does not provide implementations of protocols like *PGP.  Thorough
understanding of applied cryptography is required for safe use of
Libgcrypt.


Noteworthy changes in version 1.12.0 (2026-01-29)
-------------------------------------------------

 * New and extended interfaces:

   - Allow access to the FIPS service indicator via the new
     GCRYCTL_FIPS_SERVICE_INDICATOR control code.
     [T7338,rCd0db6a5abf,rCf51f4e9893]

   - Add GCRYCTL_FIPS_REJECT_NON_FIPS control code.  [T7338,rCe52adf0948]

   - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS constant.  [T7338,rC0414e126b9]

   - Make SHA-1 non-FIPS internally for the 1.12 API.  This introduces
     the GCRY_FIPS_FLAG_REJECT_MD_SHA1 constant.  [rC4ee91a94bc]

   - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS.  [rC0414e126b9]

   - Provide macros for each KEM enum constant.  [rCe9b1c3ec91]

   - Add Dilithium (ML-DSA) support.  [T7640]

   - Support optional random-override and support byte string data.
     [rCcbefff5fca,rC3bb4a54f43]

 * Performance:

   - Add VAES/AVX512 accelerated implementation for AES which boosts
     OCB performance by about 2 times on AMD Zen5.  [rC9e3af928ee]

   - Avoid AVX512/AVX2/SSSE3 for single block processing with Zen5 for
     ChaCha20.  [rCc1d9fff3b2]

   - Avoid AVX/AVX2/AVX512 when CPU has high vector inst latency like
     Zen5 for Blake2.  [rCe5bc3b2826]

   - Various optimizations for Camellia.
     [rCf5848080d4,rCb9bafd6c6c,rC8b538a8c76]

   - Add POLYVAL acceleration for RISC-V and GCM-SIV.  [rC00815c4207]

   - Add RISC-V Zbb+Zbc implementation of CRC.  [rCab4fa2a19c]

   - Add RISC-V vector cryptography implementation of GHASH.
     [rCcc2a4b6388]

   - Add RISC-V vector cryptography implementation of AES.
     [rCb000ab6025]

   - Add RISC-V vector cryptography implementations of SHA256 and
     SHA512.  [rCcc1d5b0b5e]

   - Add AVX2 and AVX512 code paths to improve CRC.  [rCc30788969d]

 * Bug fixes:

   - Use secure MPI in _gcry_mpi_assign_limb_space.  [rC6e77b09cff]

   - Use CSIDL_COMMON_APPDATA instead of /etc on Windows.  [rCd5e3cbfd88]

   - Apply a Kyber patch from upstream.  [rCbdc3724d72]

   - Fix an edge case in Jent initialization.  [rC0ceca9993f]

   - mceliece6688128f: Fix stack overflow crash on win64/wine
     [rC5bd9320171]

 * Other:

  - Add support for IBM z/OS, fixing -lpthread check with glibc.
    [rC5af59d8454]

  - Introduce mpi_tfr and use it for point_tfr to decrease EM signal
    and increase EM noise.  [rC4e65996bb8]

  - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN.
    [T7889]

  - Harden mask generation against branch optimization for several
    algorithms.  [e.g. rC4012e9a037,rCbf7546c502,rC052b03fb0c]

  - Improve constant-time operation for ECDSA.  [T7519,rC0bd4c77be6]


 Changes also found in 1.11.2:

 * Bug fixes:

   - Fix link errors in regression test t-thread-local on some
     platforms (e.g. NetBSD).  [T7634]

   - Add missing file to allow building for RISC-V.  [T7647]

   - Support secp256k1 by KEM API.  GnuPG has recently switched to use
     the KEM interface and a few folks are using this curve.  [T7698]

   - Fix a missing initialization in RSA's generate_fips.
     [rG292cb75a72]

 * Other:

   - Silence GCC 15 warnings [rCd5fb7cd9b3,T7617]

   - Provide a prototype for __udiv_qrnnd for PowerPC and Alpha which
     is required due to GCC-15 changes.  [T7721]

   - Add missing abi versions and machine tags for PowerPC assembly
     with GCC-15.  [T7721]

   - Use '.rodata' section for read-only data of poly1305-p10le.
     [T7721]


 Changes also found in 1.11.1:

 * Bug fixes:

   - Fix build regression on 32 bit Windows using Clang. [T7175]

   - Fix build regression on macOS due to symbol naming.  [T7170]

   - Fix Kyber secret-dependent branch introduced by recent versions
     of Clang.  [rCf765778e82]

   - Fix build regression due to the use of AVX512 in Blake.  [T7184]

   - Do not build i386 asm on amd64 and vice versa.  [T7220]

   - Fix build regression on armhf with gcc-14.  [T7226]

   - Return the proper error code on malloc failure in hex2buffer.
     [rCc51151f5b0]

   - Fix long standing bug for PRIME % 2 == 0.  [rC639b0fca15]

 * Performance:

   - Add AES Vector Permute intrinsics implementation for AArch64.
     [rC94a63aedbb]

   - Add GHASH AArch64/SIMD intrinsics implementation.  [rCfec871fd18]

   - Add RISC-V vector permute AES.  [rCb24ebd6163]

   - Add GHASH RISC-V Zbb+Zbc implementation.  [rC0f1fec12b0]

   - Add ChaCha20 RISC-V vector intrinsics implementation.
     [rC8dbee93ac2]

   - Add SHA3 acceleration for RISC-V Zbb extension.  [rC1a660068ba]

 * Other:

   - Add CET support for i386 and amd64 assembly.  [T7220]

   - Add PAC/BTI support for AArch64 asm.  [T7220]

   - Apply changes to Kyber from upstream for final FIPS 203.
     [rCcc95c36e7f]

   - Introduce an internal API for a revampled FIPS service indicator.
     [T7340]

   - Several improvements for constant time operation by the
     introduction of Least Leak Intended (LLI) variants of internal
     functions.  [T7519,T7490]

   - Remove WindowsCE support.  [T7486]


 * Interface changes relative to the 1.11.0 release:
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   GCRY_KEM_RAW_P256R1                   NEW enum and const.
   GCRYCTL_FIPS_SERVICE_INDICATOR        NEW enum.
   GCRYCTL_FIPS_REJECT_NON_FIPS          NEW enum.
   GCRY_FIPS_FLAG_REJECT_PK_FLAGS        NEW const.
   GCRY_FIPS_FLAG_REJECT_MD_SHA1         NEW const.


 For a list of links to commits and bug numbers see the release info at
 https://dev.gnupg.org/T7643



Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
at https://gnupg.org/download/mirrors.html.  On the primary server
the source tarball and its digital signature are:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2.sig

or gzip compressed:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
https://gnupg.org/download/integrity_check.html.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.12.0.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.12.0.tar.bz2.sig libgcrypt-1.12.0.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.12.0.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.12.0.tar.bz2

   and check that the output matches the first line from the
   this list:

02f80e9bc9967609b7041ef874eae4e542f240a5  libgcrypt-1.12.0.tar.bz2
1327dd6ca3ec2309ac750ef1c01cbd96432f11a8  libgcrypt-1.12.0.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.


Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
=======

For help on developing with Libgcrypt you should read the included
manual and if needed ask on the gcrypt-devel mailing list.

In case of problems specific to this release please first check
https://dev.gnupg.org/T7643 for updated information.

Please also consult the archive of the gcrypt-devel mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html .
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html .

Please see https://gnupg.org/documentation/security.html for information
on how to report security issues and for our threat model.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gcrypt-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  Several full-time employed
developers and contractors are working exclusively on GnuPG and closely
related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.

Fortunately, and this is still not common with free software, we have
now established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helping with donations.

*Thank you all*

   Your Libgcrypt hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gcrypt-devel'at'gnupg.org mailing list.

* List of Release Signing Keys:
  To guarantee that a downloaded GnuPG version has not been tampered by
  malicious entities we provide signature files for all tarballs and
  binary versions.  The keys are also signed by the long term keys of
  their respective owners.  Current releases are signed by one or more
  of these four keys:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)

    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)

    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)

    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

  The keys are available at https://gnupg.org/signature_key.html and in
  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
  Note that this mail has been signed by a different key.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
  GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

-- 
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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260129/cb1db4ee/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From rudi at heitbaum.com  Thu Jan 29 23:00:02 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Thu, 29 Jan 2026 22:00:02 +0000
Subject: Building 1.12.0 with glib-2.43 has the following const warnings.
Message-ID: <SYYP282MB0960AE540DE40D3D1B692BC5B49EA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>

I was unable to register to the bug tracker. So reporting here.

../../src/misc.c: In function '_gcry_log_printsxp':../../src/misc.c:439:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  439 |           pend = strchr (p, '\n');
     |                ^

../../tests/testdrv.c: In function 'my_spawn':
../../tests/testdrv.c:533:15: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  533 |   arg_list[0] = strrchr (pgmname, '/');
      |               ^

Ref: https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00005.html

For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260129/d6c63d3a/attachment.html>

From wk at gnupg.org  Fri Jan 30 10:32:05 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 30 Jan 2026 10:32:05 +0100
Subject: Building 1.12.0 with glib-2.43 has the following const warnings.
In-Reply-To: <SYYP282MB0960AE540DE40D3D1B692BC5B49EA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>
 (Rudi Heitbaum via Gnupg-devel's message of "Thu, 29 Jan 2026 22:00:02
 +0000")
References: <SYYP282MB0960AE540DE40D3D1B692BC5B49EA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <87sebnwine.fsf@jacob.g10code.de>

Hi!

On Thu, 29 Jan 2026 22:00, Rudi Heitbaum said:

> For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr,
> strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return
> pointers into their input arrays now have definitions as macros that
> return a pointer to a const-qualified type when the input argument is

?Breaking C for Fun and Profit?

Actually this is a useful thing but this and the new keywords break all
kind of existing code.  We can't change everything for the benefit of a
new compiler and with that break bulding the software on dozens of other
platforms.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260130/cf437fbf/attachment.sig>

From wk at gnupg.org  Fri Jan 30 15:40:35 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 30 Jan 2026 15:40:35 +0100
Subject: [PATCH GnuPG 0/2] Add support for D-Trust Card 6.1/6.4
In-Reply-To: <1974271.CQOukoFCf9@localdomain> (Mario Haustein via
 Gnupg-devel's message of "Sun, 04 Jan 2026 17:06:18 +0100")
References: <1974271.CQOukoFCf9@localdomain>
Message-ID: <87h5s3w4d8.fsf@jacob.g10code.de>

Hi Mario,

Thank you for patches and the detailed explanation.  I just pushed it so
that it will go into 2.5.18.

A minor problem was that your mailer garbled the patches due to line
wrapping.  I assume this is due to the protected headers features.  I
could not used the usual git am but had to tweak the mail.   If you will
send more patches, better use attachments.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260130/700f5096/attachment.sig>

From mario.haustein at hrz.tu-chemnitz.de  Fri Jan 30 16:31:09 2026
From: mario.haustein at hrz.tu-chemnitz.de (Mario Haustein)
Date: Fri, 30 Jan 2026 16:31:09 +0100
Subject: [PATCH GnuPG 0/2] Add support for D-Trust Card 6.1/6.4
In-Reply-To: <87h5s3w4d8.fsf@jacob.g10code.de>
References: <1974271.CQOukoFCf9@localdomain> <87h5s3w4d8.fsf@jacob.g10code.de>
Message-ID: <2348949.iZASKD2KPV@localdomain>

Am Freitag, 30. Januar 2026, 15:40:35 Mitteleurop?ische Normalzeit schrieb 
Werner Koch:
> Hi Mario,

Hi Werner,

> Thank you for patches and the detailed explanation.  I just pushed it so
> that it will go into 2.5.18.

thanks for the good news.

> A minor problem was that your mailer garbled the patches due to line
> wrapping.  I assume this is due to the protected headers features.  I
> could not used the usual git am but had to tweak the mail.   If you will
> send more patches, better use attachments.

I will use patch files in the future. Sorry for the trouble.

Just in the case you wondered why there is support for D-Trust Card 4.1/4.4 
and 6.1/6.4 in GnuPG, but not for 5.1/5.4: The 5.x-series is a dual interface 
card (contact based and NFC) and requires to establish a secure channel via 
PACE [1] on both interfaces. Are there plans to eventually support PACE in 
scdaemon? It's not a problem for me if not, but maybe this kind of cards will 
become more and more widespread in the future.

[1] https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/
Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/
tr03110/TR-03110_node.html

Kind regards
Mario
-- 
Mario Haustein
Facharbeitsgruppe Anwendungen
Universit?tsrechenzentrum

Technische Universit?t Chemnitz
Stra?e der Nationen 62 | R. 1/B303 (neu: A11.303)
09111 Chemnitz
Germany

Tel:    +49 371 531-36606

mario.haustein at hrz.tu-chemnitz.de
www.tu-chemnitz.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260130/b35e9445/attachment-0001.bin>

From rudi at heitbaum.com  Sat Jan 31 02:35:14 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 01:35:14 +0000
Subject: Building 1.12.0 with glib-2.43 has the following const warnings.
In-Reply-To: <87sebnwine.fsf@jacob.g10code.de>
References: <SYYP282MB0960AE540DE40D3D1B692BC5B49EA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>
 <87sebnwine.fsf@jacob.g10code.de>
Message-ID: <SYYP282MB096025AF68A1797A747B2874B49CA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>

Hi Werner,

Understood and agree.

I have proposed the 3 patches that address the warnings that should be fully backward compatible. I skipped fixing the the 'const' qualifier in tests/testdrv.c - given it is a test and - that the local char* arg_list is used for both const char and char pointers.

Hope these are acceptable.

Thanks
Rudi

________________________________
From: Werner Koch
Sent: Friday, January 30, 2026 8:32 PM
To: Rudi Heitbaum via Gnupg-devel
Cc: Rudi Heitbaum
Subject: Re: Building 1.12.0 with glib-2.43 has the following const warnings.

Hi!

On Thu, 29 Jan 2026 22:00, Rudi Heitbaum said:

> For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr,
> strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return
> pointers into their input arrays now have definitions as macros that
> return a pointer to a const-qualified type when the input argument is

?Breaking C for Fun and Profit?

Actually this is a useful thing but this and the new keywords break all
kind of existing code.  We can't change everything for the benefit of a
new compiler and with that break bulding the software on dozens of other
platforms.


Shalom-Salam,

   Werner

--
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/014bc181/attachment.html>

From rudi at heitbaum.com  Sat Jan 31 02:25:38 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 01:25:38 +0000
Subject: [PATCH 0/3] cleanup libgcrypt warnings
Message-ID: <aX1aEncu4TZxS03g@abf3d4a53bee>

Cleanup warnings when compiling with recent compilers. All fixes conform
to c standard and avoid using compiler specific features.

Rudi Heitbaum (3):
  tests: Cast to void to suppress warnings about unused variables
  cipher: remove unused variable idx from _gcry_pk_get_keygrip function
  Update to return a pointer to a const-qualified type to fix warning

 cipher/pubkey.c            | 3 +--
 src/misc.c                 | 4 ++--
 tests/bench-slope.c        | 1 +
 tests/prime.c              | 1 +
 tests/t-fips-service-ind.c | 1 +
 5 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.51.0



From rudi at heitbaum.com  Sat Jan 31 02:27:02 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 01:27:02 +0000
Subject: [PATCH 2/3] cipher: remove unused variable idx from
 _gcry_pk_get_keygrip function
Message-ID: <aX1aZhj4pIw4CNXW@abf3d4a53bee>

fixes:
../../cipher/pubkey.c: In function '_gcry_pk_get_keygrip':
../../cipher/pubkey.c:1005:7: warning: variable 'idx' set but not used [-Wunused-but-set-variable=]
 1005 |   int idx;
      |       ^~~
---
 cipher/pubkey.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cipher/pubkey.c b/cipher/pubkey.c
index 7b133498..7120c24f 100644
--- a/cipher/pubkey.c
+++ b/cipher/pubkey.c
@@ -1002,7 +1002,6 @@ _gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array)
   gcry_pk_spec_t *spec = NULL;
   const char *s;
   char *name = NULL;
-  int idx;
   const char *elems;
   gcry_md_hd_t md = NULL;
   int okay = 0;
@@ -1047,7 +1046,7 @@ _gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array)
   else
     {
       /* Generic method to compute a keygrip.  */
-      for (idx = 0, s = elems; *s; s++, idx++)
+      for (s = elems; *s; s++)
         {
           const char *data;
           size_t datalen;
-- 
2.51.0



From rudi at heitbaum.com  Sat Jan 31 02:26:30 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 01:26:30 +0000
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
Message-ID: <aX1aRra1Gy17hKiA@abf3d4a53bee>

Address compiler warning when variable is unused because it?s used only in assert.

../../tests/bench-slope.c: In function 'get_nsec_time':
../../tests/bench-slope.c:155:7: warning: variable 'err' set but not used [-Wunused-but-set-variable=]
  155 |   int err;
      |       ^~~

../../tests/prime.c: In function 'check_primes':
../../tests/prime.c:33:16: warning: variable 'err' set but not used [-Wunused-but-set-variable=]
   33 |   gcry_error_t err = GPG_ERR_NO_ERROR;
      |                ^~~

../../tests/t-fips-service-ind.c: In function 'check_cipher_o_s_e_d_c':
../../tests/t-fips-service-ind.c:927:7: warning: variable 'ptlen' set but not used [-Wunused-but-set-variable=]
  927 |   int ptlen;
      |       ^~~~~
---
 tests/bench-slope.c        | 1 +
 tests/prime.c              | 1 +
 tests/t-fips-service-ind.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/tests/bench-slope.c b/tests/bench-slope.c
index 4b14541b..bd869efc 100644
--- a/tests/bench-slope.c
+++ b/tests/bench-slope.c
@@ -153,6 +153,7 @@ static void
 get_nsec_time (struct nsec_time *t)
 {
   int err;
+  (void)err;
 
   err = clock_gettime (CLOCK_REALTIME, &t->ts);
   assert (err == 0);
diff --git a/tests/prime.c b/tests/prime.c
index a73eb05a..a84de58c 100644
--- a/tests/prime.c
+++ b/tests/prime.c
@@ -31,6 +31,7 @@ static void
 check_primes (void)
 {
   gcry_error_t err = GPG_ERR_NO_ERROR;
+  (void)err;
   gcry_mpi_t *factors = NULL;
   gcry_mpi_t prime = NULL;
   gcry_mpi_t g;
diff --git a/tests/t-fips-service-ind.c b/tests/t-fips-service-ind.c
index bd5dd507..cf6d5298 100644
--- a/tests/t-fips-service-ind.c
+++ b/tests/t-fips-service-ind.c
@@ -933,6 +933,7 @@ check_cipher_o_s_e_d_c (int reject)
   size_t taglen = 0;
 
   ptlen = strlen (pt);
+  (void)ptlen;
   assert (ptlen == 32);
   for (tvidx=0; tvidx < DIM(tv); tvidx++)
     {
-- 
2.51.0



From rudi at heitbaum.com  Sat Jan 31 02:27:33 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 01:27:33 +0000
Subject: [PATCH 3/3] Update to return a pointer to a const-qualified type to
 fix warning
Message-ID: <aX1ahaeqWblnSgpU@abf3d4a53bee>

../../src/misc.c: In function '_gcry_log_printsxp':
../../src/misc.c:439:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  439 |           pend = strchr (p, '\n');
      |                ^
---
 src/misc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/misc.c b/src/misc.c
index b1e8eb1c..3c6fe931 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -422,8 +422,8 @@ _gcry_log_printsxp (const char *text, gcry_sexp_t sexp)
     {
       int any = 0;
       int n_closing;
-      char *buf, *pend;
-      const char *p;
+      char *buf;
+      const char *p, *pend;
       size_t size;
 
       size = sexp_sprint (sexp, GCRYSEXP_FMT_ADVANCED, NULL, 0);
-- 
2.51.0



From jcb62281 at gmail.com  Sat Jan 31 05:06:14 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Fri, 30 Jan 2026 22:06:14 -0600
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <aX1aRra1Gy17hKiA@abf3d4a53bee>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee>
Message-ID: <a4e9ab5d-5854-4dde-8cba-ca42b7645b81@gmail.com>

On 1/30/26 19:26, Rudi Heitbaum via Gnupg-devel wrote:
> Address compiler warning when variable is unused because it?s used only in assert.

Does this mean that the assertions are not actually being checked?? If 
so, that could be a bit of a problem, given that these are in testsuite 
code.

In other words, does this patch "paper over" actual bugs that GCC has 
uncovered?


-- Jacob




From rudi at heitbaum.com  Sat Jan 31 05:19:20 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 04:19:20 +0000
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <a4e9ab5d-5854-4dde-8cba-ca42b7645b81@gmail.com>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee>
 <a4e9ab5d-5854-4dde-8cba-ca42b7645b81@gmail.com>
Message-ID: <SYYP282MB096078DA527EBDEEC7E9DB4DB49CA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>

When compiling a Release build (without assert) these come up as unused.

Alternative approach would be to Error the compile when test is part of the build but assert is not part of the build due to the build being Release.

________________________________
From: Jacob Bachmeyer <jcb62281 at gmail.com>
Sent: Saturday, January 31, 2026 15:06
To: Rudi Heitbaum <rudi at heitbaum.com>; gnupg-devel at gnupg.org <gnupg-devel at gnupg.org>
Subject: Re: [PATCH 1/3] tests: Cast to void to suppress warnings about unused variables

On 1/30/26 19:26, Rudi Heitbaum via Gnupg-devel wrote:
> Address compiler warning when variable is unused because it?s used only in assert.

Does this mean that the assertions are not actually being checked?  If
so, that could be a bit of a problem, given that these are in testsuite
code.

In other words, does this patch "paper over" actual bugs that GCC has
uncovered?


-- Jacob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/f949bb81/attachment-0001.html>

From jcb62281 at gmail.com  Sat Jan 31 05:34:28 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Fri, 30 Jan 2026 22:34:28 -0600
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <SYYP282MB096078DA527EBDEEC7E9DB4DB49CA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee>
 <a4e9ab5d-5854-4dde-8cba-ca42b7645b81@gmail.com>
 <SYYP282MB096078DA527EBDEEC7E9DB4DB49CA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>
Message-ID: <fcf750c5-f96b-4d92-aae9-cf26c3d95c96@gmail.com>

On 1/30/26 22:19, Rudi Heitbaum wrote:
> When compiling a Release build (without assert) these come up as unused.
>
> Alternative approach would be to Error the compile when test is part 
> of the build but assert is not part of the build due to the build 
> being Release.

Another option would be to override that and enforce that assertions are 
always checked in the test suite, even in release builds.


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260130/fbebd14c/attachment.html>

From wk at gnupg.org  Sat Jan 31 14:39:01 2026
From: wk at gnupg.org (Werner Koch)
Date: Sat, 31 Jan 2026 14:39:01 +0100
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about
 unused variables
In-Reply-To: <aX1aRra1Gy17hKiA@abf3d4a53bee> (Rudi Heitbaum via Gnupg-devel's
 message of "Sat, 31 Jan 2026 01:26:30 +0000")
References: <aX1aRra1Gy17hKiA@abf3d4a53bee>
Message-ID: <87bji9x5oq.fsf@jacob.g10code.de>

On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
> Address compiler warning when variable is unused because it?s used
> only in assert.

Anyone who defines NDEBUG does not known what s/he does.  An assert is
there for a reason.  It is plain stupid to use an assert but disable it
for production.


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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/5c1cb0a6/attachment.sig>

From wk at gnupg.org  Sat Jan 31 14:45:09 2026
From: wk at gnupg.org (Werner Koch)
Date: Sat, 31 Jan 2026 14:45:09 +0100
Subject: [PATCH GnuPG 0/2] Add support for D-Trust Card 6.1/6.4
In-Reply-To: <2348949.iZASKD2KPV@localdomain> (Mario Haustein via
 Gnupg-devel's message of "Fri, 30 Jan 2026 16:31:09 +0100")
References: <1974271.CQOukoFCf9@localdomain> <87h5s3w4d8.fsf@jacob.g10code.de>
 <2348949.iZASKD2KPV@localdomain>
Message-ID: <877bsxx5ei.fsf@jacob.g10code.de>

On Fri, 30 Jan 2026 16:31, Mario Haustein said:
> PACE [1] on both interfaces. Are there plans to eventually support PACE in 
> scdaemon? It's not a problem for me if not, but maybe this kind of cards will 

Support for secure channel is on the todo list for a very long time.  It
would also be helpful for Yubikeys.  I am not sure, but isn't it the
case that the German identity card also requires PACE?  In that case I
should consider to an identity card in addition to my passport.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/2e6386c1/attachment.sig>

From noloader at gmail.com  Sat Jan 31 15:55:23 2026
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 31 Jan 2026 09:55:23 -0500
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <87bji9x5oq.fsf@jacob.g10code.de>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee> <87bji9x5oq.fsf@jacob.g10code.de>
Message-ID: <CAH8yC8m+wBzSB9yDhpO0cc5+FPi5Vh1NJEWDb9pGX-z+BRAckw@mail.gmail.com>

On Sat, Jan 31, 2026 at 8:36?AM Werner Koch via Gnupg-devel <
gnupg-devel at gnupg.org> wrote:

> On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
> > Address compiler warning when variable is unused because it?s used
> > only in assert.
>
> Anyone who defines NDEBUG does not known what s/he does.  An assert is
> there for a reason.  It is plain stupid to use an assert but disable it
> for production.


Asserts are a debugging and diagnostic tool.  Confer, <
https://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html>.
Asserts should not be enabled in production software.

If an assert triggers, it usually causes a program to crash.  Sensitive
data can leave the app's security boundary and be egressed through the
crash dump or report.  Companies like Apple, Canonical, Google and
Microsoft could have access to the sensitive data.

I've even seen asserts used in BitCoin wallets, and the crash reports
uploaded to Microsoft App Center Diagnostics.  The private keys for the
wallets were burned!

I've never seen a project document that private keys and shared secrets
should be rotated after a program crashes due to an assert.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/36cbd587/attachment.html>

From collin.funk1 at gmail.com  Sat Jan 31 20:21:03 2026
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sat, 31 Jan 2026 11:21:03 -0800
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about
 unused variables
In-Reply-To: <CAH8yC8m+wBzSB9yDhpO0cc5+FPi5Vh1NJEWDb9pGX-z+BRAckw@mail.gmail.com>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee> <87bji9x5oq.fsf@jacob.g10code.de>
 <CAH8yC8m+wBzSB9yDhpO0cc5+FPi5Vh1NJEWDb9pGX-z+BRAckw@mail.gmail.com>
Message-ID: <87jywxeggw.fsf@gmail.com>

Jeffrey Walton via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> On Sat, Jan 31, 2026 at 8:36?AM Werner Koch via Gnupg-devel <
> gnupg-devel at gnupg.org> wrote:
>
>> On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
>> > Address compiler warning when variable is unused because it?s used
>> > only in assert.
>>
>> Anyone who defines NDEBUG does not known what s/he does.  An assert is
>> there for a reason.  It is plain stupid to use an assert but disable it
>> for production.
>
>
> Asserts are a debugging and diagnostic tool.  Confer, <
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html>.
> Asserts should not be enabled in production software.

I generally agree, but there is some benefit to having a program crash
instead of continuing in an undefined state.

> If an assert triggers, it usually causes a program to crash.  Sensitive
> data can leave the app's security boundary and be egressed through the
> crash dump or report.  Companies like Apple, Canonical, Google and
> Microsoft could have access to the sensitive data.
>
> I've even seen asserts used in BitCoin wallets, and the crash reports
> uploaded to Microsoft App Center Diagnostics.  The private keys for the
> wallets were burned!
>
> I've never seen a project document that private keys and shared secrets
> should be rotated after a program crashes due to an assert.

Yeah, that is bad.

Collin


From rudi at heitbaum.com  Sat Jan 31 22:59:00 2026
From: rudi at heitbaum.com (Rudi Heitbaum)
Date: Sat, 31 Jan 2026 21:59:00 +0000
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <87bji9x5oq.fsf@jacob.g10code.de>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee> <87bji9x5oq.fsf@jacob.g10code.de>
Message-ID: <SYYP282MB0960AC90C5EF96267D75BD28B49CA@SYYP282MB0960.AUSP282.PROD.OUTLOOK.COM>

Werner, Very well know what an assert is if you are intending this comment to me.

In production we would not be using tests.
So perhaps as option could be added to disable-test builds to configure? Would this be acceptable? It would allow for clean, warning free compiles, which would have to be a good thing for security software?

Regards
Rudi

________________________________
From: Werner Koch <wk at gnupg.org>
Sent: Sunday, February 1, 2026 00:35
To: Rudi Heitbaum via Gnupg-devel <gnupg-devel at gnupg.org>
Cc: Rudi Heitbaum <rudi at heitbaum.com>
Subject: Re: [PATCH 1/3] tests: Cast to void to suppress warnings about unused variables

On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
> Address compiler warning when variable is unused because it?s used
> only in assert.

Anyone who defines NDEBUG does not known what s/he does. An assert is
there for a reason. It is plain stupid to use an assert but disable it
for production.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260131/c42d0abc/attachment-0001.html>