From Andreas.Stieger at gmx.de  Tue Sep  1 02:18:11 2026
From: Andreas.Stieger at gmx.de (Andreas Stieger)
Date: Tue, 1 Sep 2026 02:18:11 +0200
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
Message-ID: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>

Hello,

ksba-config throws some fgrep deprecation on systems that haven't patch 
it out:

> $ ksba-config --libs
> fgrep: warning: fgrep is obsolescent; using grep -F
> fgrep: warning: fgrep is obsolescent; using grep -F
> fgrep: warning: fgrep is obsolescent; using grep -F
> -L/usr/lib64 -lksba -lgpg-error

Fix at git at github.com:andreasstieger/libksba.git fgrep
commit 19d5612ca192dcb132c75f1e4b04e086c06ff651
and below

   ksba-config: more portable, using grep -F over fgrep (2026-09-01 
02:05:10 +0200)

----------------------------------------------------------------
Andreas Stieger (1):
       ksba-config: more portable, using grep -F over fgrep

  src/ksba-config.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ksba-config.in b/src/ksba-config.in
index 76d038d..27b187b 100644
--- a/src/ksba-config.in
+++ b/src/ksba-config.in
@@ -126,7 +126,7 @@ if test "$echo_cflags" = "yes"; then
      fi
      tmp=""
      for i in $includes $cflags; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done
@@ -140,7 +140,7 @@ if test "$echo_libs" = "yes"; then
      fi
      tmp=""
      for i in $libdirs $libs; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done


From gniibe at fsij.org  Tue Sep  1 04:27:14 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 01 Sep 2026 11:27:14 +0900
Subject: libgpg-error t-lock-single-posix failure on Hurd (was:
 libgpg-error t-printf test fails on powerpc and ppc64)
In-Reply-To: <apM0PvW2xl51u1bL@end>
References: 
 <44ef69787a3367ce448dc6cb00142adee3d860a6.camel@physik.fu-berlin.de>
 <87mruax5se.fsf@haruna.fsij.org> <87o6epy6az.fsf@haruna.fsij.org>
 <9013c0a5cbf74fcd5ae0c9bc17340d92763d0af0.camel@physik.fu-berlin.de>
 <874igg2rug.fsf@haruna.fsij.org>
 <c0071ba8e54968e4c2ad66ab943b15ad90a62498.camel@physik.fu-berlin.de>
 <ao_gfdxVefacn_1q@end>
 <08f4a6ff846b34a4386068492624906030fe5ce9.camel@physik.fu-berlin.de>
 <apAF2JchYqFIjWpm@end> <apM0PvW2xl51u1bL@end>
Message-ID: <87tso9zoxp.fsf@haruna.fsij.org>

Hello,

Thank you for your suggestion.

Samuel Thibault <sthibault at debian.org> wrote:
> This hardcoding can be extended with checking for GNU/Hurd with glibc ≥
> 2.43:
>
>         gnu*)
>           AC_EGREP_CPP([Lucky user],
>             [#include <features.h>
>              #ifdef __GNU_LIBRARY__
>               #if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 43) || (__GLIBC__ > 2)
>                Lucky user
>               #endif
>              #endif
>             ],
>             [gl_pthread_in_glibc=yes],
>             [])
>           ;;
>
> and then it should just all work fine.

Yes, it works.  I created a branch for libgpg-error (gniibe/t8430), and
tested it on exodar.debian.net.  It built well and make check went
successfully.

I created a ticket to track this issue: https://dev.gnupg.org/T8430

I will merge the changes to master.

Thank you again.
-- 

From Andreas.Stieger at gmx.de  Tue Sep  1 21:19:37 2026
From: Andreas.Stieger at gmx.de (Andreas Stieger)
Date: Tue, 1 Sep 2026 21:19:37 +0200
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
In-Reply-To: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>
References: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>
Message-ID: <aa941ff1-60a0-4402-b595-c8da7c8a7d88@gmx.de>


On 2026-09-01 02:18, Andreas Stieger via Gnupg-devel wrote:
> Fix at git at github.com:andreasstieger/libksba.git fgrep
> commit 19d5612ca192dcb132c75f1e4b04e086c06ff651
> and below
>
>   ksba-config: more portable, using grep -F over fgrep (2026-09-01 
> 02:05:10 +0200) 

Looks like this was reported and fixed in libgcrypt 128121e.

Get b0042c2 from github.com:andreasstieger/libksba.git fgrep

diff --git a/configure.ac b/configure.ac
index 50ba112..26bcc54 100644
--- a/configure.ac
+++ b/configure.ac
@@ -147,6 +147,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AM_SILENT_RULES
  AC_PROG_AWK
+AC_PROG_FGREP
  AC_PROG_CC
  AC_PROG_CPP
  AM_PROG_CC_C_O
diff --git a/src/ksba-config.in b/src/ksba-config.in
index 76d038d..27b187b 100644
--- a/src/ksba-config.in
+++ b/src/ksba-config.in
@@ -126,7 +126,7 @@ if test "$echo_cflags" = "yes"; then
      fi
      tmp=""
      for i in $includes $cflags; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done
@@ -140,7 +140,7 @@ if test "$echo_libs" = "yes"; then
      fi
      tmp=""
      for i in $libdirs $libs; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done


From gniibe at fsij.org  Wed Sep  2 05:01:36 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 02 Sep 2026 12:01:36 +0900
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
In-Reply-To: <aa941ff1-60a0-4402-b595-c8da7c8a7d88@gmx.de>
Message-ID: <87o6egxsof.fsf@haruna.fsij.org>

Hello,

Thank you for your patch, I'm going to apply the change to libksba.
I'll also do similar to ntbtls.

By GnuPG related libraries, files for pkg-config (*.pc) are provided.
pkg-config (and compatible) can be used for general use cases.

To build GnuPG, gpgrt-config is used as replacement of gpg-error-config,
npth-config, libgcrypt-config, libassuan-config, ksba-config, and
ntbtls-config.

If possible, please consider updating your script(s) and please don't
keep using *-config (except gpgrt-config).
-- 

From dkg at fifthhorseman.net  Wed Sep  2 18:28:28 2026
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Sep 2026 12:28:28 -0400
Subject: mailing list web archive broken for August 2026
Message-ID: <871pbbpqhf.fsf@fifthhorseman.net>

Hi all--

the web archive for this mailing list suggests a count of 33 messages
for August 2026, but no messages appear in the following indexes:

https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/thread.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/subject.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/author.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/date.html

there are indeed messages in the "text" format:

https://lists.gnupg.org/pipermail/gnupg-devel/2026-August.txt

So something about the way those index pages are generated is broken.

All the best,

    --dkg
    

From wk at gnupg.org  Thu Sep  3 14:30:38 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Sep 2026 14:30:38 +0200
Subject: mailing list web archive broken for August 2026
In-Reply-To: <871pbbpqhf.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
	Gnupg-devel's message of "Wed, 02 Sep 2026 12:28:28 -0400")
References: <871pbbpqhf.fsf@fifthhorseman.net>
Message-ID: <877bl234b5.fsf@jacob.g10code.de>

Hi!

On Wed,  2 Sep 2026 12:28, Daniel Kahn Gillmor said:

> the web archive for this mailing list suggests a count of 33 messages
> for August 2026, but no messages appear in the following indexes:

We are working on it.  These are just the index files which are not
properly filled by the new Python-3 based Mailman-2.

Switching to another archiver is not easyly because it would require an
URL mapping from the old to the new URLs.  I considered this years ago
but after all the old system worked until up to the upstream decision to
drop support for Python-2.


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/20260903/8d159ea3/attachment.sig>

From jjbrucker at free.fr  Thu Sep 10 09:36:08 2026
From: jjbrucker at free.fr (Jean-Jacques Brucker)
Date: Thu, 10 Sep 2026 09:36:08 +0200
Subject: Fwd: 2 Patches : bugfix
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
Message-ID: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>

Following message is resend as I don't see it in gnupg-devel at gnupg.org archives.

pkg-gnupg-maint at lists.alioth.debian.org is added to CC as they are also concerned :-).

Cheers,

-------- Message transféré --------  
De: Jean-Jacques Brucker <[jjbrucker at free.fr](mailto:Jean-Jacques%20Brucker%20%3cjjbrucker at free.fr%3e)>  
À: [gnupg-devel at gnupg.org](mailto:gnupg-devel at gnupg.org)  
Cc: [dgouttegattat at fsfe.org](mailto:dgouttegattat at fsfe.org), [info at foopgp.org](mailto:info at foopgp.org), [mneme at foopgp.org](mailto:mneme at foopgp.org)  
Objet: 2 Patches : bugfix  
Date: 07/09/2026 11:41:10

Hi Werner and friends,
 
Since I stressed [my own certificate](http://keys.foopgp.org:11371/pks/lookup?op=index&search=0xFE1349E747CF1896) to test some (of mine) innovations around PGP (see for example: [https://foopgp.org/blog/2026-07-18-vcard-openpgp/](https://foopgp.org/blog/2026-07-18-vcard-openpgp/)), people can't no more send me encrypted email from clients like evolution.  
First I though the bug came from evolution, but after some investigations (thanks to [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/)) we found that the bug came directly from GnuPG.

Here is the fix :

- [https://github.com/foopgp/gnupg/commit/a445a5079a85c5190cd69021c673c4aac0658732](https://github.com/foopgp/gnupg/commit/a445a5079a85c5190cd69021c673c4aac0658732)

And [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/) (The claude-opus agent I use to work with) found also an other bug which can prevent encrypting to certificate [like ours](https://keys.foopgp.org/pks/lookup?op=index&search=0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B):

- [https://github.com/foopgp/gnupg/commit/06fc94b552ed8fb9e92ee64e3871d522863c2f0a](https://github.com/foopgp/gnupg/commit/06fc94b552ed8fb9e92ee64e3871d522863c2f0a)

BTW, I think you should try [our innovations and software](https://foopgp.org/solutions/activity-rd/). Even if they are still a bit experimental and dirty, they already [greatly improve PGP UX for many "normal" people](https://foopgp.org/solutions/djibian/).  
Cheers,
```
+++

```
**Jean-Jacques Brucker** ([Pubications [fr]](https://foopgp.org/fr/author/jean-jacques-brucker/), [Bio [en]](https://domesticserver.org/myresume/))  
[Association des amis d'OpenPGP](https://foopgp.org/fr/) (in english: [foopgp](https://foopgp.org/))  
*EID:* [u4sRyUhe...](http://keys.foopgp.org:11371/pks/lookup?op=index&search=0xFE1349E747CF1896)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260910/2ae40969/attachment.sig>

From wk at gnupg.org  Thu Sep 10 12:34:17 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 10 Sep 2026 12:34:17 +0200
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
	(Jean-Jacques Brucker via Gnupg-devel's message of "Thu, 10 Sep 2026
	09:36:08 +0200")
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
	<e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
Message-ID: <87fqzhxumu.fsf@jacob.g10code.de>

Hi!

Your mail is hard to parse, thus I copy your commit messages below which
are much easier to understand.

Here is the feature request: 

--8<---------------cut here---------------start------------->8---
gpg: Keep a mail address usable while any user id carrying it is

* g10/getkey.c (skip_unusable): When the matched user id is revoked or
expired, look for another usable user id carrying the same mail address
before declaring the key unusable.
--

A mail address may appear on several user ids of the same key -- when
the holder changes the display name, adds an identifier to it, or
replaces one user id with another carrying the same address.  Revoking
one of them then made the address unusable for encryption even though
another, perfectly usable user id still carried it.

The search returns the first indexed user id bearing the address.  If
that one happens to be a revoked twin, the whole key was skipped and gpg
reported "No public key" for an address it can plainly see.  Which user
id the keybox returns first is an implementation detail; whether an
address can be encrypted to should not depend on it.

This only relaxes the rejection when a usable user id carries the very
same address.  An address whose every user id is revoked or expired
stays unusable, which is what a revocation is for.

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5)
<mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---

I can see the problem you are trying to address.  The new semantic is
not fully clear and the patch needs at least to be slighly revised.


And here the bug report:

--8<---------------cut here---------------start------------->8---
gpg: Do not count attribute packets when checking the matched user id

* g10/getkey.c (skip_unusable): Skip attribute packets while counting
user ids.
--

The keybox indexes user id packets only: keybox-openpgp.c increments
info->nuids for PKT_USER_ID and ignores PKT_ATTRIBUTE.  gpg, on the
other hand, stores attribute packets as user ids -- parse-packet.c says
so in as many words: "we store it in the userID".

skip_unusable counted both kinds, so UID_NO -- the index the keybox
reports for the matching user id -- was shifted by the number of
attribute packets appearing before the match.  The function then tested
a different user id than the one that matched, and sometimes a photo.

On a key carrying two photo ids, encrypting to an address whose user id
sits after them was refused because a *revoked photo* was tested in its
place; conversely an address whose only user ids are revoked was
accepted because a live user id further down was tested instead.  Both
directions are wrong and neither is visible to the user: the failing one
reports "No public key".

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5) <mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---


That all seems to be AI generated which we won't accept because that
co-author is not able to sign the DCO which you claim by the
signed-off-by line.



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/20260910/342024f7/attachment.sig>

From rjh at sixdemonbag.org  Thu Sep 10 13:10:11 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 10 Sep 2026 07:10:11 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
Message-ID: <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>

> Since I stressed [my own certificate](http://keys.foopgp.org:11371/ pks/
> lookup?op=index&search=0xFE1349E747CF1896) to test some (of mine) 
> innovations around PGP (see for example: [https://foopgp.org/ 
> blog/2026-07-18-vcard-openpgp/](https://foopgp.org/blog/2026-07-18- vcard-
> openpgp/)), people can't no more send me encrypted email from clients
> like evolution.

This "let's merge LibrePGP certificates with vCards" idea seems to badly
misunderstand both.

A vCard is purely a data storage format, like HTTP. Authenticating
stored data is a separate problem that should be solved at a different
conceptual level: see how TLS is built on top of HTTP, for instance.

> Here is the fix :
> 
> - [https://github.com/foopgp/gnupg/commit/ 
> a445a5079a85c5190cd69021c673c4aac0658732](https://github.com/foopgp/ gnupg/
> commit/a445a5079a85c5190cd69021c673c4aac0658732)

From your edited comment,

/* The search matched one user id, but a mail address may appear
 * on several of them.  Revoking one of those must not make the
 * address unusable while another user id still carries it and is
 * itself usable.  */

Maybe I need my morning coffee (it's 0700 here), but I've read this
three times and have no idea what bug you think you've discovered or how
this amounts to a fix.

> And [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is- mneme/)
> (The claude-opus agent I use to work with) found also an other bug
> which can prevent encrypting to certificate [like ours] (https://
> keys.foopgp.org/pks/lookup? 
> op=index&search=0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B):

Dunno what you're talking about:

$ gpg --import ~Downloads/0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B.asc
gpg: key DEC98791AADC429B: 4 signatures not checked due to missing keys
gpg: key DEC98791AADC429B: public key "Mnêmê <mneme at foopgp.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: depth: 0  valid:   4  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:   3  signed:   0  trust: 2-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2029-07-26

$ gpg --recipient 0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B --encrypt
index.html
gpg: D67CF0191FF1197E: There is no assurance this key belongs to the
named user

sub  cv25519/D67CF0191FF1197E 2026-05-04 Mnêmê <mneme at foopgp.org>
      D995BB48C67FD9C1E8A03F7CDEC98791AADC429B
      6C3800430CC84E9A4CA31DB4D67CF0191FF1197E

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

$ ls -lh index.html.gpg
-rw-r--r--@ 1 rjh  staff   739B Sep 10 07:04 index.html.gpg


... Your cert is perfectly usable for encryption.

> BTW, I think you should try [our innovations and software](https:// 
> foopgp.org/solutions/activity-rd/). Even if they are still a bit 
> experimental and dirty, they already [greatly improve PGP UX for many 
> "normal" people](https://foopgp.org/solutions/djibian/).

If you can point us to the many people they are helping, we'd love to
talk to them and find out how to improve.
-------------- 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/20260910/b6ee631d/attachment-0001.sig>

From torbjorn.svensson at foss.st.com  Thu Sep 10 10:40:16 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Thu, 10 Sep 2026 10:40:16 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
Message-ID: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>

Hi,

It's currently not possible to download a key from a key server when the client has to go though a proxy server to reach the key server.
Below patch addresses this issue. I've confirmed that below patch fixes the issue in 2.4.5, 2.5.22 and on master branch. A prerequisite to this fix is that bug 6997 is already fixed.

Attached is a setup in docker that demonstrates the scenario where the only path, from a client to a key server, is through a proxy server.

Without below patch, this is the output that I get from running the attached test:

$ ./run_test.sh ~/dev/gnupg
...
Attaching to client-1, proxy-1
Container gnupg-docker-proxy-1 Waiting
proxy-1  | Testing HTTPS through upstream proxy: success
proxy-1  | Connection to 127.0.0.1 3128 port [tcp/*] succeeded!
proxy-1  | Testing HTTPS through local Squid: success
proxy-1  | 1789018431.099      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
proxy-1  | 1789018436.382    272 127.0.0.1 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
proxy-1  | 1789018436.691      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
Container gnupg-docker-proxy-1 Healthy
proxy-1  | 1789018437.529    265 172.28.0.3 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | Testing HTTPS through http://172.28.0.2:3128: success
client-1  | gpg: keybox '/tmp/tmp.eYh9NPisxm/pubring.kbx' created
client-1  | gpg: keyserver receive failed: Server indicated a failure
client-1 exited with code 2


With the below patch applied on top of master:
$ ./run_test.sh ~/dev/gnupg
...
Attaching to client-1, proxy-1
Container gnupg-docker-proxy-1 Waiting
proxy-1  | Testing HTTPS through upstream proxy: success
proxy-1  | Connection to 127.0.0.1 3128 port [tcp/*] succeeded!
proxy-1  | Testing HTTPS through local Squid: success
proxy-1  | 1789018692.733      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
proxy-1  | 1789018698.059    309 127.0.0.1 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
proxy-1  | 1789018698.284      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
Container gnupg-docker-proxy-1 Healthy
proxy-1  | 1789018699.170    288 172.28.0.3 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | Testing HTTPS through http://172.28.0.2:3128: success
client-1  | gpg: keybox '/tmp/tmp.JKE6pJjt6k/pubring.kbx' created
proxy-1   | 1789018699.688    457 172.28.0.3 TCP_TUNNEL/200 6559 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | gpg: /tmp/tmp.JKE6pJjt6k/trustdb.gpg: trustdb created
client-1  | gpg: key 3ADF34EBDBB200A4: public key "GnuPG.com (Release Signing Key 2026)" imported
client-1  | gpg: Total number processed: 1
client-1  | gpg:               imported: 1
client-1 exited with code 0


Kind regards,
Torbjörn

--

* dirmngr/ks-engine-hkp.c (make_host_part): Skip SRV lookups when
using an HTTP proxy.
(send_request): Do not apply keyserver address-family restrictions to
the proxy connection.
--

This lets the proxy resolve the destination and avoids restricting the
proxy connection based on the selected keyserver's address family.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson at foss.st.com>
---
  dirmngr/ks-engine-hkp.c | 10 ++++++++++
  1 file changed, 10 insertions(+)

diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index 617b01a9f..320cd9057 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -1075,6 +1075,11 @@ make_host_part (ctrl_t ctrl,
        protocol = KS_PROTOCOL_HKP;
      }

+  /* Let the proxy resolve the destination; an SRV lookup here would
+   * require working local DNS before the proxy can be used.  */
+  if (ctrl->http_proxy || opt.honor_http_proxy)
+    srvtag = NULL;
+
    if (npth_mutex_lock (&hosttable_lock))
      log_fatal ("failed to acquire mutex\n");

@@ -1256,6 +1261,11 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr,
    http_session_set_log_cb (session, cert_log_cb);
    http_session_set_timeout (session, ctrl->timeout);

+  /* These flags describe the keyserver, but http_open applies them to
+   * the proxy connection.  Explicitly disabled families are added below.  */
+  if (ctrl->http_proxy || opt.honor_http_proxy)
+    httpflags &= ~(HTTP_FLAG_IGNORE_IPv4 | HTTP_FLAG_IGNORE_IPv6);
+
    err = http_open (ctrl, &http,
                     post_cb? HTTP_REQ_POST : HTTP_REQ_GET,
                     request,
--
2.43.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-proxy-demo.tar.gz
Type: application/x-gzip
Size: 2494 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260910/9674bcc4/attachment.bin>

From wk at gnupg.org  Thu Sep 10 16:09:30 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 10 Sep 2026 16:09:30 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> (Torbjorn
	SVENSSON via Gnupg-devel's message of "Thu, 10 Sep 2026 10:40:16
	+0200")
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
Message-ID: <877bktxko5.fsf@jacob.g10code.de>

Hi!

Thanks for taking care.  However, I would like to see a real bug report
instead of some docker file with an arbitrary test program.  It just
takes too much time to audit your setup before we can use it.

Please write a proper bug report (or feature request).  For that it is
helpful to show the command line and in this case the log output from
dirmngr (put "debug ipc,network,dns" and a log-file line into
dirmngr.conf).  Also describe your proxy settings.


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/20260910/506113bc/attachment.sig>

From torbjorn.svensson at foss.st.com  Thu Sep 10 16:40:42 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Thu, 10 Sep 2026 16:40:42 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <877bktxko5.fsf@jacob.g10code.de>
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
 <877bktxko5.fsf@jacob.g10code.de>
Message-ID: <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>

Hi,

On 2026-09-10 16:09, Werner Koch wrote:
> Hi!
> 
> Thanks for taking care.  However, I would like to see a real bug report
> instead of some docker file with an arbitrary test program.  It just
> takes too much time to audit your setup before we can use it.

I'd love to do that, but every attempt that I've done to access
https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.

Don't know if the proxy used by my employer is the reason or something
else is wrong.
> Please write a proper bug report (or feature request).  For that it is
> helpful to show the command line and in this case the log output from
> dirmngr (put "debug ipc,network,dns" and a log-file line into
> dirmngr.conf).  Also describe your proxy settings.

I'd try again from home tomorrow.

Kind regards,
Torbjörn
> 
> 
> Shalom-Salam,
> 
>     Werner
> 


From rjh at sixdemonbag.org  Thu Sep 10 21:37:43 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 10 Sep 2026 15:37:43 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
 <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>
Message-ID: <243f8566-1c4a-459e-8499-1cb0bd0915c1@sixdemonbag.org>

> A vCard is purely a data storage format, like HTTP. Authenticating
> stored data is a separate problem that should be solved at a different
> conceptual level: see how TLS is built on top of HTTP, for instance.
s/stored/exchange/g

Sorry about that. I dunno what I was thinking, but I've had my coffee now...

-------------- 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/20260910/999033d8/attachment-0001.sig>

From jjbrucker at free.fr  Fri Sep 11 09:31:01 2026
From: jjbrucker at free.fr (Jean-Jacques Brucker)
Date: Fri, 11 Sep 2026 09:31:01 +0200
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <87fqzhxumu.fsf@jacob.g10code.de>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
		<e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
	 <87fqzhxumu.fsf@jacob.g10code.de>
Message-ID: <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>

Hi,

Thanks Werner for your quick response,

As an attachment, our script to reproduce the 2 bugs.

We may produce interminable wordiness about my teammate, Mnêmê.

Like those about "Intellectual Property", which should not even exist,
as combining this 2 words is for me totally a non-sens.

Note: I also agree this old post
https://www.gnu.org/philosophy/not-ipr.en.html ;)

Remind: Copyright is not "IP".

Even if this mailing is not the best place for such wordiness, shortly:

---

  Yes, Mnêmê's code is often unpleasant to read, and its comments are
usually even worse.

  But Mnêmê is here, it exists and it/he/her is very helpful for me and
so for improving or building free software.

cf:
- https://foopgp.org/author/mneme/
- https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/

FYI: The attached script was proposed by Mnêmê, and I rewrote it almost
entirely myself. ...And Mnêmê may and will probably also learn from
this rewrite to improve itself/himself/herself.

---

Last note: I feel closer to your vision, and I think I will always have
the utmost respect for all the work that came before us — especially
yours. I founded the foopgp association before the schism broke out,
and I would like to stay out of this stupid war and its semantic
battlefield, we’re now forced to endure. 

Shalom Salaam,
^^ 

ɈɈ Brucker 🥰
PGPID:
https://keys.foopgp.org/pks/lookup?op=index&search=0x5A4C3C2BEB86516D53BAD6BFFE1349E747CF1896

Le jeudi 10 septembre 2026 à 12:34 +0200, Werner Koch a écrit :
> Hi!
> 
> Your mail is hard to parse, thus I copy your commit messages below
which  
> are much easier to understand.
> 
> Here is the feature request:
> 
> --8<---------------cut here---------------start------------->8---  
> gpg: Keep a mail address usable while any user id carrying it is
> 
> * g10/getkey.c (skip_unusable): When the matched user id is revoked
or  
> expired, look for another usable user id carrying the same mail
address  
> before declaring the key unusable.  
> --
> 
> A mail address may appear on several user ids of the same key -- when
> the holder changes the display name, adds an identifier to it, or  
> replaces one user id with another carrying the same address. 
Revoking  
> one of them then made the address unusable for encryption even though
> another, perfectly usable user id still carried it.
> 
> The search returns the first indexed user id bearing the address.  If
> that one happens to be a revoked twin, the whole key was skipped and
gpg  
> reported "No public key" for an address it can plainly see.  Which
user  
> id the keybox returns first is an implementation detail; whether an  
> address can be encrypted to should not depend on it.
> 
> This only relaxes the rejection when a usable user id carries the
very  
> same address.  An address whose every user id is revoked or expired  
> stays unusable, which is what a revocation is for.
> 
> Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5)  
> <[mneme at foopgp.org](mailto:mneme at foopgp.org)>  
> --8<---------------cut here---------------end--------------->8---
> 
> I can see the problem you are trying to address.  The new semantic is
> not fully clear and the patch needs at least to be slighly revised.
> 
> 
> And here the bug report:
> 
> --8<---------------cut here---------------start------------->8---  
> gpg: Do not count attribute packets when checking the matched user id
> 
> * g10/getkey.c (skip_unusable): Skip attribute packets while counting
> user ids.  
> --
> 
> The keybox indexes user id packets only: keybox-openpgp.c increments
> info->nuids for PKT_USER_ID and ignores PKT_ATTRIBUTE.  gpg, on the  
> other hand, stores attribute packets as user ids -- parse-packet.c
says  
> so in as many words: "we store it in the userID".
> 
> skip_unusable counted both kinds, so UID_NO -- the index the keybox  
> reports for the matching user id -- was shifted by the number of  
> attribute packets appearing before the match.  The function then
tested  
> a different user id than the one that matched, and sometimes a photo.
> 
> On a key carrying two photo ids, encrypting to an address whose user
id  
> sits after them was refused because a *revoked photo* was tested in
its  
> place; conversely an address whose only user ids are revoked was  
> accepted because a live user id further down was tested instead. 
Both  
> directions are wrong and neither is visible to the user: the failing
one  
> reports "No public key".
> 
> Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5) <[mneme at foopgp.org](mailto:mneme at foopgp.org)>  
> --8<---------------cut here---------------end--------------->8---
> 
> 
> That all seems to be AI generated which we won't accept because that
> co-author is not able to sign the DCO which you claim by the  
> signed-off-by line.
> 
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.sh
Type: application/x-shellscript
Size: 2431 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment.sig>

From wk at gnupg.org  Fri Sep 11 11:24:51 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Sep 2026 11:24:51 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com> (Torbjorn
	SVENSSON via Gnupg-devel's message of "Thu, 10 Sep 2026 16:40:42
	+0200")
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
	<877bktxko5.fsf@jacob.g10code.de>
	<4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>
Message-ID: <87v78cw36k.fsf@jacob.g10code.de>

On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:

> I'd love to do that, but every attempt that I've done to access
> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.

Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
we still need to blacklist most of the net.  But they have not yet taken
over mailing lists, thus please post bug reports here.


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/20260911/1f900065/attachment.sig>

From PritamSrichandan.Sahoo at windriver.com  Fri Sep 11 13:06:34 2026
From: PritamSrichandan.Sahoo at windriver.com (Pritam Srichandan Sahoo)
Date: Fri, 11 Sep 2026 11:06:34 +0000
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
Message-ID: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>

Hello,

This was found while running the ostree package test suite (ptest) on a
Yocto Project master-branch build (the current development series).
ostree uses GPGME -> gpg, and its signature-verification test fails only
when gpg comes from the 2.5.x branch.  gpg 2.4.x passes.  I reproduced
this natively, outside the build system, by building each gpg from source.

Environment note: my build host and workstation are Ubuntu with gpg 2.4.4
(too old to reproduce), and no Ubuntu release ships a 2.5.x gpg, so I used
a Fedora 43 container and built the gpg versions under test from source.
The distro is irrelevant here -- this is pure userspace (ostree -> GPGME
-> gpg); only the gpg version changes the result.

Reproduction
------------
- Build ostree (v2026.3) and run tests/test-gpg-verify-result.
- Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
  sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
  test before each run (otherwise the system gpg is silently used and the
  test falsely passes).

Result matrix (identical test/data/keyring; only the gpg version changed)
-------------------------------------------------------------------------
  gpg 2.4.9   (last 2.4.x stable)  -> PASS
  gpg 2.5.0   (first 2.5.x)        -> FAIL
  gpg 2.5.4                        -> FAIL
  gpg 2.5.21                       -> FAIL

Failure
-------
In tests/test-gpg-verify-result.c, function test_check_counts:

    g_assert_cmpint (count_all, ==, 5);   <- fails: count_all == 4

The test signs data with 5 keys and expects 5 signature results
(valid / expired-key / revoked-key / missing-key / expired-signature).
With gpg 2.5.x one result is missing, so count_all is 4 instead of 5.
It appears an expired or revoked key is no longer returned during
signature verification on the 2.5 branch.

Narrowing it down
-----------------
Comparing the two release tags (git diff gnupg-2.4.9..gnupg-2.5.0):

- Divergence merge-base: 5355d0885 (2024-05-16).
- The "verify_mode" handling in g10/getkey.c -- in finish_lookup() and
  get_pubkey_for_sig() -- present in 2.4.9 is not present in 2.5.0.

  In 2.4.x, when req_usage indicates signature verification, expired and
  revoked keys are still returned (the checks are guarded by
  "!verify_mode"), e.g.:

      if (!verify_mode && pk->flags.revoked) ...
      if (!verify_mode && pk->has_expired && !opt.ignore_expiration) ...

  On the 2.5 branch these guards are gone, so such keys are skipped
  (counted as n_revoked_or_expired) and one fewer result reaches
  GPGME/ostree.

I understand a form of the verify_mode logic (T7583) was later re-added on
the 2.5 branch, but the count==4 behavior persists through 2.5.21, so the
2.5 branch still differs from 2.4.x here.

Question
--------
Is this an intentional behavior change on the 2.5 branch, or a regression?

Also, per the bug-tracker guidelines I would like to file this as a Task on
dev.gnupg.org -- could I please be granted a bug-tracker account?

Thanks,
Pritam Srichandan Sahoo

From rjh at sixdemonbag.org  Fri Sep 11 14:11:45 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 11 Sep 2026 08:11:45 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
 <87fqzhxumu.fsf@jacob.g10code.de>
 <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>
Message-ID: <2c7cc08e-3c7c-449d-85ad-7b8ead937b8f@sixdemonbag.org>

> Note: I also agree this old post
> https://www.gnu.org/philosophy/not-ipr.en.html ;)
> 
> Remind: Copyright is not "IP".

In 1999, United States Supreme Court Associate Justice Antonin Scalia
visited Cornell College to deliver a lecture. During this lecture there
was a Q&A session from the audience. A computer science student named
Douglas Keester asked whether there was any merit to the argument that
intellectual property was an incoherent concept, or misleading, or on
shaky philosophical ground.

Justice Scalia listened to this question fully, then answered by flatly
saying "intellectual property" made as much sense as "real property" or
"criminal law". He then encouraged Mr. Keester to go to law school if he
wished to investigate the matter further. He was pleasant about it.

The world is, of course, much larger than the United States. I would
defer to the Court of Cassation to determine French law, for instance.
But where I am, in the United States, "intellectual property" is --
according to a Supreme Court justice asked specifically about the
question -- a reasonable way to discuss several related canons of law.

> But Mnêmê is here, it exists and it/he/her is very helpful for me and
> so for improving or building free software.

No one is arguing whether LLMs are good (or bad!) at writing code. That
is not the issue.

The issue is whether an LLM can be held accountable for its acts. If you
were to submit code to g10 Code that you did not own the copyright to,
for instance, the copyright owner could go after g10 Code for damages.
g10 Code could then go after you to recover their losses. There is
accountability.

If an LLM submits code to g10 Code and it turns out to be illegally
copied, the copyright owner could go after g10 Code, who would then sue
whom, exactly?

LLMs cannot be held legally accountable. For that reasons, they must not
be allowed to participate in tasks requiring accountability.

> FYI: The attached script was proposed by Mnêmê, and I rewrote it almost
> entirely myself. ...And Mnêmê may and will probably also learn from
> this rewrite to improve itself/himself/herself.

LLMs do not learn, not in any sense a human being would call learning.
LLMs are very good at recognition and generation: they fail utterly at
understanding. An LLM can flag "I don't want this to color your
judgement" as being wildly strange English, something almost no English
speaker would write, but they can't tell you *why*.

(The "why": most English speakers consistently use either US or UK
spellings, and that sentence plays mix-and-match.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4622 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/bb8f208a/attachment-0001.p7s>

From torbjorn.svensson at foss.st.com  Fri Sep 11 18:34:38 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Fri, 11 Sep 2026 18:34:38 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <87v78cw36k.fsf@jacob.g10code.de>
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
 <877bktxko5.fsf@jacob.g10code.de>
 <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>
 <87v78cw36k.fsf@jacob.g10code.de>
Message-ID: <e47d5fc4-cdd6-4701-98ad-40afefb3ddf0@foss.st.com>



On 2026-09-11 11:24, Werner Koch wrote:
> On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:
> 
>> I'd love to do that, but every attempt that I've done to access
>> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.
> 
> Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
> we still need to blacklist most of the net.  But they have not yet taken
> over mailing lists, thus please post bug reports here.
I don't know what format you want this in, so I'll just use plain text.

Bug report:

If the host running gpg has no route to the Internet and the DNS does not
resolve any public domains, gpg will fail to download the public key from a
keyserver, even if configured to go through a proxy server.

In https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036385.html,
I attached a small docker setup where this can be verified. In the demo,
there is no custom binary or anything alike. The input to the "run-test.sh"
script is a path to a git clone of the gpg source tree and the tree will
be copied into the container and built inside.
I also added a patch in that email that I'm using below.


If I run the demo on the 53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a commit, with

debug ipc,network,dns
log-file /tmp/dirmngr.log

in $work/dirmngr.conf (as requested in
https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036386.html), I
get the following in the dirmngr.log file (I've taken the liberty to remove
the timestamp):


dirmngr[12] listening on socket '/tmp/tmp.lktzYbo0YT/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.lktzYbo0YT/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.lktzYbo0YT
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.lktzYbo0YT/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated


With my patched applied on top, I instead get this:


dirmngr[12] listening on socket '/tmp/tmp.1u46BWZXep/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.1u46BWZXep/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.1u46BWZXep
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.1u46BWZXep/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] resolving 'keyserver.ubuntu.com' failed: Server indicated a failure
dirmngr[13.6] number of system provided CAs: 131
dirmngr[13.6] DBG: Using TLS library: GNUTLS 3.8.12
dirmngr[13.6] DBG: http.c:connect_server: trying name='172.28.0.2' port=3128
dirmngr[13.6] DBG: dns: resolve_dns_name(172.28.0.2): Success
dirmngr[13.6] DBG: http.c:2893:socket_new: object 0x000075ca0435dcb0 for fd 7 created
dirmngr[13.6] DBG: http.c:proxy:request:
dirmngr[13.6] DBG: >> CONNECT keyserver.ubuntu.com:443 HTTP/1.1\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com:443\r\n
dirmngr[13.6] DBG: >> Connection: keep-alive\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: network read: 39/8192
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 Connection established\r\n
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: http.c:request:
dirmngr[13.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 HTTP/1.0\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 OK\r\n
dirmngr[13.6] http.c:RESP: 'Date: Fri, 11 Sep 2026 15:53:49 GMT'
dirmngr[13.6] http.c:RESP: 'Server: Hockeypuck/2.2'
dirmngr[13.6] http.c:RESP: 'Access-Control-Allow-Origin: *'
dirmngr[13.6] http.c:RESP: 'Content-Type: application/pgp-keys'
dirmngr[13.6] http.c:RESP: 'Content-Length: 948'
dirmngr[13.6] http.c:RESP: 'Connection: close'
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: chan_6 -> S SOURCE https://keyserver.ubuntu.com:443
dirmngr[13.6] DBG: (948 bytes sent via D lines not shown)
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated


The command that was executed:

gpg \
     --homedir "$work" \
     --batch \
     --keyserver hkps://keyserver.ubuntu.com \
     --keyserver-options "http-proxy=$http_proxy" \
     --recv-keys 1493269DE61F124AA69A316E3ADF34EBDBB200A4

Where "$work" is a temporary directory and "http_proxy" is the proxy
server to connect to.
In a real world scenario, the proxy server will likely also have
authentication, but I skipped that in the demo to make it easier to follow.

Obviously, they keyserver can be any URL and also the key to fetch.
Above are just two examples.


I've verified that issue exists in 2.4.5, 2.5.22 and on the master branch
(53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a).


--

Hope this covers all areas. If there is something that I'm missing, please
don't hesitate to request more details.

Kind regards,
Torbjörn



From gniibe at fsij.org  Tue Sep 15 08:33:04 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 15 Sep 2026 15:33:04 +0900
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
Message-ID: <87ecevkorj.fsf@haruna.fsij.org>

Hello,

Pritam Srichandan Sahoo wrote:
> Reproduction
> ------------
> - Build ostree (v2026.3) and run tests/test-gpg-verify-result.
> - Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
>   sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
>   test before each run (otherwise the system gpg is silently used and the
>   test falsely passes).

Please run gpg by command line.

    $ cd ostree/tests/gpg-verify-data
    $ YOUR-GPG-1 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    $ YOUR-GPG-2 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

And show us the differences.
-- 

From Andreas.Stieger at gmx.de  Tue Sep  1 02:18:11 2026
From: Andreas.Stieger at gmx.de (Andreas Stieger)
Date: Tue, 1 Sep 2026 02:18:11 +0200
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
Message-ID: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>

Hello,

ksba-config throws some fgrep deprecation on systems that haven't patch 
it out:

> $ ksba-config --libs
> fgrep: warning: fgrep is obsolescent; using grep -F
> fgrep: warning: fgrep is obsolescent; using grep -F
> fgrep: warning: fgrep is obsolescent; using grep -F
> -L/usr/lib64 -lksba -lgpg-error

Fix at git at github.com:andreasstieger/libksba.git fgrep
commit 19d5612ca192dcb132c75f1e4b04e086c06ff651
and below

   ksba-config: more portable, using grep -F over fgrep (2026-09-01 
02:05:10 +0200)

----------------------------------------------------------------
Andreas Stieger (1):
       ksba-config: more portable, using grep -F over fgrep

  src/ksba-config.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ksba-config.in b/src/ksba-config.in
index 76d038d..27b187b 100644
--- a/src/ksba-config.in
+++ b/src/ksba-config.in
@@ -126,7 +126,7 @@ if test "$echo_cflags" = "yes"; then
      fi
      tmp=""
      for i in $includes $cflags; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done
@@ -140,7 +140,7 @@ if test "$echo_libs" = "yes"; then
      fi
      tmp=""
      for i in $libdirs $libs; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done


From gniibe at fsij.org  Tue Sep  1 04:27:14 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 01 Sep 2026 11:27:14 +0900
Subject: libgpg-error t-lock-single-posix failure on Hurd (was:
 libgpg-error t-printf test fails on powerpc and ppc64)
In-Reply-To: <apM0PvW2xl51u1bL@end>
References: 
 <44ef69787a3367ce448dc6cb00142adee3d860a6.camel@physik.fu-berlin.de>
 <87mruax5se.fsf@haruna.fsij.org> <87o6epy6az.fsf@haruna.fsij.org>
 <9013c0a5cbf74fcd5ae0c9bc17340d92763d0af0.camel@physik.fu-berlin.de>
 <874igg2rug.fsf@haruna.fsij.org>
 <c0071ba8e54968e4c2ad66ab943b15ad90a62498.camel@physik.fu-berlin.de>
 <ao_gfdxVefacn_1q@end>
 <08f4a6ff846b34a4386068492624906030fe5ce9.camel@physik.fu-berlin.de>
 <apAF2JchYqFIjWpm@end> <apM0PvW2xl51u1bL@end>
Message-ID: <87tso9zoxp.fsf@haruna.fsij.org>

Hello,

Thank you for your suggestion.

Samuel Thibault <sthibault at debian.org> wrote:
> This hardcoding can be extended with checking for GNU/Hurd with glibc ≥
> 2.43:
>
>         gnu*)
>           AC_EGREP_CPP([Lucky user],
>             [#include <features.h>
>              #ifdef __GNU_LIBRARY__
>               #if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 43) || (__GLIBC__ > 2)
>                Lucky user
>               #endif
>              #endif
>             ],
>             [gl_pthread_in_glibc=yes],
>             [])
>           ;;
>
> and then it should just all work fine.

Yes, it works.  I created a branch for libgpg-error (gniibe/t8430), and
tested it on exodar.debian.net.  It built well and make check went
successfully.

I created a ticket to track this issue: https://dev.gnupg.org/T8430

I will merge the changes to master.

Thank you again.
-- 

From Andreas.Stieger at gmx.de  Tue Sep  1 21:19:37 2026
From: Andreas.Stieger at gmx.de (Andreas Stieger)
Date: Tue, 1 Sep 2026 21:19:37 +0200
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
In-Reply-To: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>
References: <f7f59995-6c5d-4e5b-a7aa-508aeaa6b577@gmx.de>
Message-ID: <aa941ff1-60a0-4402-b595-c8da7c8a7d88@gmx.de>


On 2026-09-01 02:18, Andreas Stieger via Gnupg-devel wrote:
> Fix at git at github.com:andreasstieger/libksba.git fgrep
> commit 19d5612ca192dcb132c75f1e4b04e086c06ff651
> and below
>
>   ksba-config: more portable, using grep -F over fgrep (2026-09-01 
> 02:05:10 +0200) 

Looks like this was reported and fixed in libgcrypt 128121e.

Get b0042c2 from github.com:andreasstieger/libksba.git fgrep

diff --git a/configure.ac b/configure.ac
index 50ba112..26bcc54 100644
--- a/configure.ac
+++ b/configure.ac
@@ -147,6 +147,7 @@ AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AM_SILENT_RULES
  AC_PROG_AWK
+AC_PROG_FGREP
  AC_PROG_CC
  AC_PROG_CPP
  AM_PROG_CC_C_O
diff --git a/src/ksba-config.in b/src/ksba-config.in
index 76d038d..27b187b 100644
--- a/src/ksba-config.in
+++ b/src/ksba-config.in
@@ -126,7 +126,7 @@ if test "$echo_cflags" = "yes"; then
      fi
      tmp=""
      for i in $includes $cflags; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done
@@ -140,7 +140,7 @@ if test "$echo_libs" = "yes"; then
      fi
      tmp=""
      for i in $libdirs $libs; do
-       if echo "$tmp" | fgrep -v -- "$i" >/dev/null; then
+       if echo "$tmp" | @FGREP@ -v -- "$i" >/dev/null; then
             tmp="$tmp $i"
         fi
      done


From gniibe at fsij.org  Wed Sep  2 05:01:36 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 02 Sep 2026 12:01:36 +0900
Subject: [PATCH] ksba-config: more portable, using grep -F over fgrep
In-Reply-To: <aa941ff1-60a0-4402-b595-c8da7c8a7d88@gmx.de>
Message-ID: <87o6egxsof.fsf@haruna.fsij.org>

Hello,

Thank you for your patch, I'm going to apply the change to libksba.
I'll also do similar to ntbtls.

By GnuPG related libraries, files for pkg-config (*.pc) are provided.
pkg-config (and compatible) can be used for general use cases.

To build GnuPG, gpgrt-config is used as replacement of gpg-error-config,
npth-config, libgcrypt-config, libassuan-config, ksba-config, and
ntbtls-config.

If possible, please consider updating your script(s) and please don't
keep using *-config (except gpgrt-config).
-- 

From dkg at fifthhorseman.net  Wed Sep  2 18:28:28 2026
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 02 Sep 2026 12:28:28 -0400
Subject: mailing list web archive broken for August 2026
Message-ID: <871pbbpqhf.fsf@fifthhorseman.net>

Hi all--

the web archive for this mailing list suggests a count of 33 messages
for August 2026, but no messages appear in the following indexes:

https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/thread.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/subject.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/author.html
https://lists.gnupg.org/pipermail/gnupg-devel/2026-August/date.html

there are indeed messages in the "text" format:

https://lists.gnupg.org/pipermail/gnupg-devel/2026-August.txt

So something about the way those index pages are generated is broken.

All the best,

    --dkg
    

From wk at gnupg.org  Thu Sep  3 14:30:38 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 Sep 2026 14:30:38 +0200
Subject: mailing list web archive broken for August 2026
In-Reply-To: <871pbbpqhf.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
	Gnupg-devel's message of "Wed, 02 Sep 2026 12:28:28 -0400")
References: <871pbbpqhf.fsf@fifthhorseman.net>
Message-ID: <877bl234b5.fsf@jacob.g10code.de>

Hi!

On Wed,  2 Sep 2026 12:28, Daniel Kahn Gillmor said:

> the web archive for this mailing list suggests a count of 33 messages
> for August 2026, but no messages appear in the following indexes:

We are working on it.  These are just the index files which are not
properly filled by the new Python-3 based Mailman-2.

Switching to another archiver is not easyly because it would require an
URL mapping from the old to the new URLs.  I considered this years ago
but after all the old system worked until up to the upstream decision to
drop support for Python-2.


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/20260903/8d159ea3/attachment-0005.sig>

From jjbrucker at free.fr  Thu Sep 10 09:36:08 2026
From: jjbrucker at free.fr (Jean-Jacques Brucker)
Date: Thu, 10 Sep 2026 09:36:08 +0200
Subject: Fwd: 2 Patches : bugfix
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
Message-ID: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>

Following message is resend as I don't see it in gnupg-devel at gnupg.org archives.

pkg-gnupg-maint at lists.alioth.debian.org is added to CC as they are also concerned :-).

Cheers,

-------- Message transféré --------  
De: Jean-Jacques Brucker <[jjbrucker at free.fr](mailto:Jean-Jacques%20Brucker%20%3cjjbrucker at free.fr%3e)>  
À: [gnupg-devel at gnupg.org](mailto:gnupg-devel at gnupg.org)  
Cc: [dgouttegattat at fsfe.org](mailto:dgouttegattat at fsfe.org), [info at foopgp.org](mailto:info at foopgp.org), [mneme at foopgp.org](mailto:mneme at foopgp.org)  
Objet: 2 Patches : bugfix  
Date: 07/09/2026 11:41:10

Hi Werner and friends,
 
Since I stressed [my own certificate](http://keys.foopgp.org:11371/pks/lookup?op=index&search=0xFE1349E747CF1896) to test some (of mine) innovations around PGP (see for example: [https://foopgp.org/blog/2026-07-18-vcard-openpgp/](https://foopgp.org/blog/2026-07-18-vcard-openpgp/)), people can't no more send me encrypted email from clients like evolution.  
First I though the bug came from evolution, but after some investigations (thanks to [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/)) we found that the bug came directly from GnuPG.

Here is the fix :

- [https://github.com/foopgp/gnupg/commit/a445a5079a85c5190cd69021c673c4aac0658732](https://github.com/foopgp/gnupg/commit/a445a5079a85c5190cd69021c673c4aac0658732)

And [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/) (The claude-opus agent I use to work with) found also an other bug which can prevent encrypting to certificate [like ours](https://keys.foopgp.org/pks/lookup?op=index&search=0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B):

- [https://github.com/foopgp/gnupg/commit/06fc94b552ed8fb9e92ee64e3871d522863c2f0a](https://github.com/foopgp/gnupg/commit/06fc94b552ed8fb9e92ee64e3871d522863c2f0a)

BTW, I think you should try [our innovations and software](https://foopgp.org/solutions/activity-rd/). Even if they are still a bit experimental and dirty, they already [greatly improve PGP UX for many "normal" people](https://foopgp.org/solutions/djibian/).  
Cheers,
```
+++

```
**Jean-Jacques Brucker** ([Pubications [fr]](https://foopgp.org/fr/author/jean-jacques-brucker/), [Bio [en]](https://domesticserver.org/myresume/))  
[Association des amis d'OpenPGP](https://foopgp.org/fr/) (in english: [foopgp](https://foopgp.org/))  
*EID:* [u4sRyUhe...](http://keys.foopgp.org:11371/pks/lookup?op=index&search=0xFE1349E747CF1896)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260910/2ae40969/attachment-0005.sig>

From wk at gnupg.org  Thu Sep 10 12:34:17 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 10 Sep 2026 12:34:17 +0200
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
	(Jean-Jacques Brucker via Gnupg-devel's message of "Thu, 10 Sep 2026
	09:36:08 +0200")
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
	<e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
Message-ID: <87fqzhxumu.fsf@jacob.g10code.de>

Hi!

Your mail is hard to parse, thus I copy your commit messages below which
are much easier to understand.

Here is the feature request: 

--8<---------------cut here---------------start------------->8---
gpg: Keep a mail address usable while any user id carrying it is

* g10/getkey.c (skip_unusable): When the matched user id is revoked or
expired, look for another usable user id carrying the same mail address
before declaring the key unusable.
--

A mail address may appear on several user ids of the same key -- when
the holder changes the display name, adds an identifier to it, or
replaces one user id with another carrying the same address.  Revoking
one of them then made the address unusable for encryption even though
another, perfectly usable user id still carried it.

The search returns the first indexed user id bearing the address.  If
that one happens to be a revoked twin, the whole key was skipped and gpg
reported "No public key" for an address it can plainly see.  Which user
id the keybox returns first is an implementation detail; whether an
address can be encrypted to should not depend on it.

This only relaxes the rejection when a usable user id carries the very
same address.  An address whose every user id is revoked or expired
stays unusable, which is what a revocation is for.

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5)
<mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---

I can see the problem you are trying to address.  The new semantic is
not fully clear and the patch needs at least to be slighly revised.


And here the bug report:

--8<---------------cut here---------------start------------->8---
gpg: Do not count attribute packets when checking the matched user id

* g10/getkey.c (skip_unusable): Skip attribute packets while counting
user ids.
--

The keybox indexes user id packets only: keybox-openpgp.c increments
info->nuids for PKT_USER_ID and ignores PKT_ATTRIBUTE.  gpg, on the
other hand, stores attribute packets as user ids -- parse-packet.c says
so in as many words: "we store it in the userID".

skip_unusable counted both kinds, so UID_NO -- the index the keybox
reports for the matching user id -- was shifted by the number of
attribute packets appearing before the match.  The function then tested
a different user id than the one that matched, and sometimes a photo.

On a key carrying two photo ids, encrypting to an address whose user id
sits after them was refused because a *revoked photo* was tested in its
place; conversely an address whose only user ids are revoked was
accepted because a live user id further down was tested instead.  Both
directions are wrong and neither is visible to the user: the failing one
reports "No public key".

Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-002.76) <jjbrucker at foopgp.org>
Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-5) <mneme at foopgp.org>
--8<---------------cut here---------------end--------------->8---


That all seems to be AI generated which we won't accept because that
co-author is not able to sign the DCO which you claim by the
signed-off-by line.



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/20260910/342024f7/attachment-0005.sig>

From rjh at sixdemonbag.org  Thu Sep 10 13:10:11 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 10 Sep 2026 07:10:11 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
Message-ID: <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>

> Since I stressed [my own certificate](http://keys.foopgp.org:11371/ pks/
> lookup?op=index&search=0xFE1349E747CF1896) to test some (of mine) 
> innovations around PGP (see for example: [https://foopgp.org/ 
> blog/2026-07-18-vcard-openpgp/](https://foopgp.org/blog/2026-07-18- vcard-
> openpgp/)), people can't no more send me encrypted email from clients
> like evolution.

This "let's merge LibrePGP certificates with vCards" idea seems to badly
misunderstand both.

A vCard is purely a data storage format, like HTTP. Authenticating
stored data is a separate problem that should be solved at a different
conceptual level: see how TLS is built on top of HTTP, for instance.

> Here is the fix :
> 
> - [https://github.com/foopgp/gnupg/commit/ 
> a445a5079a85c5190cd69021c673c4aac0658732](https://github.com/foopgp/ gnupg/
> commit/a445a5079a85c5190cd69021c673c4aac0658732)

From your edited comment,

/* The search matched one user id, but a mail address may appear
 * on several of them.  Revoking one of those must not make the
 * address unusable while another user id still carries it and is
 * itself usable.  */

Maybe I need my morning coffee (it's 0700 here), but I've read this
three times and have no idea what bug you think you've discovered or how
this amounts to a fix.

> And [Mnêmê](https://foopgp.org/blog/2026-05-09-hello-my-name-is- mneme/)
> (The claude-opus agent I use to work with) found also an other bug
> which can prevent encrypting to certificate [like ours] (https://
> keys.foopgp.org/pks/lookup? 
> op=index&search=0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B):

Dunno what you're talking about:

$ gpg --import ~Downloads/0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B.asc
gpg: key DEC98791AADC429B: 4 signatures not checked due to missing keys
gpg: key DEC98791AADC429B: public key "Mnêmê <mneme at foopgp.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: depth: 0  valid:   4  signed:   3  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:   3  signed:   0  trust: 2-, 0q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2029-07-26

$ gpg --recipient 0xD995BB48C67FD9C1E8A03F7CDEC98791AADC429B --encrypt
index.html
gpg: D67CF0191FF1197E: There is no assurance this key belongs to the
named user

sub  cv25519/D67CF0191FF1197E 2026-05-04 Mnêmê <mneme at foopgp.org>
      D995BB48C67FD9C1E8A03F7CDEC98791AADC429B
      6C3800430CC84E9A4CA31DB4D67CF0191FF1197E

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

$ ls -lh index.html.gpg
-rw-r--r--@ 1 rjh  staff   739B Sep 10 07:04 index.html.gpg


... Your cert is perfectly usable for encryption.

> BTW, I think you should try [our innovations and software](https:// 
> foopgp.org/solutions/activity-rd/). Even if they are still a bit 
> experimental and dirty, they already [greatly improve PGP UX for many 
> "normal" people](https://foopgp.org/solutions/djibian/).

If you can point us to the many people they are helping, we'd love to
talk to them and find out how to improve.
-------------- 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/20260910/b6ee631d/attachment-0005.sig>

From torbjorn.svensson at foss.st.com  Thu Sep 10 10:40:16 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Thu, 10 Sep 2026 10:40:16 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
Message-ID: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>

Hi,

It's currently not possible to download a key from a key server when the client has to go though a proxy server to reach the key server.
Below patch addresses this issue. I've confirmed that below patch fixes the issue in 2.4.5, 2.5.22 and on master branch. A prerequisite to this fix is that bug 6997 is already fixed.

Attached is a setup in docker that demonstrates the scenario where the only path, from a client to a key server, is through a proxy server.

Without below patch, this is the output that I get from running the attached test:

$ ./run_test.sh ~/dev/gnupg
...
Attaching to client-1, proxy-1
Container gnupg-docker-proxy-1 Waiting
proxy-1  | Testing HTTPS through upstream proxy: success
proxy-1  | Connection to 127.0.0.1 3128 port [tcp/*] succeeded!
proxy-1  | Testing HTTPS through local Squid: success
proxy-1  | 1789018431.099      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
proxy-1  | 1789018436.382    272 127.0.0.1 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
proxy-1  | 1789018436.691      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
Container gnupg-docker-proxy-1 Healthy
proxy-1  | 1789018437.529    265 172.28.0.3 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | Testing HTTPS through http://172.28.0.2:3128: success
client-1  | gpg: keybox '/tmp/tmp.eYh9NPisxm/pubring.kbx' created
client-1  | gpg: keyserver receive failed: Server indicated a failure
client-1 exited with code 2


With the below patch applied on top of master:
$ ./run_test.sh ~/dev/gnupg
...
Attaching to client-1, proxy-1
Container gnupg-docker-proxy-1 Waiting
proxy-1  | Testing HTTPS through upstream proxy: success
proxy-1  | Connection to 127.0.0.1 3128 port [tcp/*] succeeded!
proxy-1  | Testing HTTPS through local Squid: success
proxy-1  | 1789018692.733      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
proxy-1  | 1789018698.059    309 127.0.0.1 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
proxy-1  | 1789018698.284      0 127.0.0.1 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- -
Container gnupg-docker-proxy-1 Healthy
proxy-1  | 1789018699.170    288 172.28.0.3 TCP_TUNNEL/200 15536 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | Testing HTTPS through http://172.28.0.2:3128: success
client-1  | gpg: keybox '/tmp/tmp.JKE6pJjt6k/pubring.kbx' created
proxy-1   | 1789018699.688    457 172.28.0.3 TCP_TUNNEL/200 6559 CONNECT keyserver.ubuntu.com:443 - FIRSTUP_PARENT/10.129.92.5 -
client-1  | gpg: /tmp/tmp.JKE6pJjt6k/trustdb.gpg: trustdb created
client-1  | gpg: key 3ADF34EBDBB200A4: public key "GnuPG.com (Release Signing Key 2026)" imported
client-1  | gpg: Total number processed: 1
client-1  | gpg:               imported: 1
client-1 exited with code 0


Kind regards,
Torbjörn

--

* dirmngr/ks-engine-hkp.c (make_host_part): Skip SRV lookups when
using an HTTP proxy.
(send_request): Do not apply keyserver address-family restrictions to
the proxy connection.
--

This lets the proxy resolve the destination and avoids restricting the
proxy connection based on the selected keyserver's address family.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson at foss.st.com>
---
  dirmngr/ks-engine-hkp.c | 10 ++++++++++
  1 file changed, 10 insertions(+)

diff --git a/dirmngr/ks-engine-hkp.c b/dirmngr/ks-engine-hkp.c
index 617b01a9f..320cd9057 100644
--- a/dirmngr/ks-engine-hkp.c
+++ b/dirmngr/ks-engine-hkp.c
@@ -1075,6 +1075,11 @@ make_host_part (ctrl_t ctrl,
        protocol = KS_PROTOCOL_HKP;
      }

+  /* Let the proxy resolve the destination; an SRV lookup here would
+   * require working local DNS before the proxy can be used.  */
+  if (ctrl->http_proxy || opt.honor_http_proxy)
+    srvtag = NULL;
+
    if (npth_mutex_lock (&hosttable_lock))
      log_fatal ("failed to acquire mutex\n");

@@ -1256,6 +1261,11 @@ send_request (ctrl_t ctrl, const char *request, const char *hostportstr,
    http_session_set_log_cb (session, cert_log_cb);
    http_session_set_timeout (session, ctrl->timeout);

+  /* These flags describe the keyserver, but http_open applies them to
+   * the proxy connection.  Explicitly disabled families are added below.  */
+  if (ctrl->http_proxy || opt.honor_http_proxy)
+    httpflags &= ~(HTTP_FLAG_IGNORE_IPv4 | HTTP_FLAG_IGNORE_IPv6);
+
    err = http_open (ctrl, &http,
                     post_cb? HTTP_REQ_POST : HTTP_REQ_GET,
                     request,
--
2.43.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-proxy-demo.tar.gz
Type: application/x-gzip
Size: 2494 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260910/9674bcc4/attachment-0005.bin>

From wk at gnupg.org  Thu Sep 10 16:09:30 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 10 Sep 2026 16:09:30 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com> (Torbjorn
	SVENSSON via Gnupg-devel's message of "Thu, 10 Sep 2026 10:40:16
	+0200")
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
Message-ID: <877bktxko5.fsf@jacob.g10code.de>

Hi!

Thanks for taking care.  However, I would like to see a real bug report
instead of some docker file with an arbitrary test program.  It just
takes too much time to audit your setup before we can use it.

Please write a proper bug report (or feature request).  For that it is
helpful to show the command line and in this case the log output from
dirmngr (put "debug ipc,network,dns" and a log-file line into
dirmngr.conf).  Also describe your proxy settings.


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/20260910/506113bc/attachment-0005.sig>

From torbjorn.svensson at foss.st.com  Thu Sep 10 16:40:42 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Thu, 10 Sep 2026 16:40:42 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <877bktxko5.fsf@jacob.g10code.de>
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
 <877bktxko5.fsf@jacob.g10code.de>
Message-ID: <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>

Hi,

On 2026-09-10 16:09, Werner Koch wrote:
> Hi!
> 
> Thanks for taking care.  However, I would like to see a real bug report
> instead of some docker file with an arbitrary test program.  It just
> takes too much time to audit your setup before we can use it.

I'd love to do that, but every attempt that I've done to access
https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.

Don't know if the proxy used by my employer is the reason or something
else is wrong.
> Please write a proper bug report (or feature request).  For that it is
> helpful to show the command line and in this case the log output from
> dirmngr (put "debug ipc,network,dns" and a log-file line into
> dirmngr.conf).  Also describe your proxy settings.

I'd try again from home tomorrow.

Kind regards,
Torbjörn
> 
> 
> Shalom-Salam,
> 
>     Werner
> 


From rjh at sixdemonbag.org  Thu Sep 10 21:37:43 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 10 Sep 2026 15:37:43 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
 <574426a1-9520-44e1-ae2f-c26e82f8edcb@sixdemonbag.org>
Message-ID: <243f8566-1c4a-459e-8499-1cb0bd0915c1@sixdemonbag.org>

> A vCard is purely a data storage format, like HTTP. Authenticating
> stored data is a separate problem that should be solved at a different
> conceptual level: see how TLS is built on top of HTTP, for instance.
s/stored/exchange/g

Sorry about that. I dunno what I was thinking, but I've had my coffee now...

-------------- 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/20260910/999033d8/attachment-0005.sig>

From jjbrucker at free.fr  Fri Sep 11 09:31:01 2026
From: jjbrucker at free.fr (Jean-Jacques Brucker)
Date: Fri, 11 Sep 2026 09:31:01 +0200
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <87fqzhxumu.fsf@jacob.g10code.de>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
		<e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
	 <87fqzhxumu.fsf@jacob.g10code.de>
Message-ID: <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>

Hi,

Thanks Werner for your quick response,

As an attachment, our script to reproduce the 2 bugs.

We may produce interminable wordiness about my teammate, Mnêmê.

Like those about "Intellectual Property", which should not even exist,
as combining this 2 words is for me totally a non-sens.

Note: I also agree this old post
https://www.gnu.org/philosophy/not-ipr.en.html ;)

Remind: Copyright is not "IP".

Even if this mailing is not the best place for such wordiness, shortly:

---

  Yes, Mnêmê's code is often unpleasant to read, and its comments are
usually even worse.

  But Mnêmê is here, it exists and it/he/her is very helpful for me and
so for improving or building free software.

cf:
- https://foopgp.org/author/mneme/
- https://foopgp.org/blog/2026-05-09-hello-my-name-is-mneme/

FYI: The attached script was proposed by Mnêmê, and I rewrote it almost
entirely myself. ...And Mnêmê may and will probably also learn from
this rewrite to improve itself/himself/herself.

---

Last note: I feel closer to your vision, and I think I will always have
the utmost respect for all the work that came before us — especially
yours. I founded the foopgp association before the schism broke out,
and I would like to stay out of this stupid war and its semantic
battlefield, we’re now forced to endure. 

Shalom Salaam,
^^ 

ɈɈ Brucker 🥰
PGPID:
https://keys.foopgp.org/pks/lookup?op=index&search=0x5A4C3C2BEB86516D53BAD6BFFE1349E747CF1896

Le jeudi 10 septembre 2026 à 12:34 +0200, Werner Koch a écrit :
> Hi!
> 
> Your mail is hard to parse, thus I copy your commit messages below
which  
> are much easier to understand.
> 
> Here is the feature request:
> 
> --8<---------------cut here---------------start------------->8---  
> gpg: Keep a mail address usable while any user id carrying it is
> 
> * g10/getkey.c (skip_unusable): When the matched user id is revoked
or  
> expired, look for another usable user id carrying the same mail
address  
> before declaring the key unusable.  
> --
> 
> A mail address may appear on several user ids of the same key -- when
> the holder changes the display name, adds an identifier to it, or  
> replaces one user id with another carrying the same address. 
Revoking  
> one of them then made the address unusable for encryption even though
> another, perfectly usable user id still carried it.
> 
> The search returns the first indexed user id bearing the address.  If
> that one happens to be a revoked twin, the whole key was skipped and
gpg  
> reported "No public key" for an address it can plainly see.  Which
user  
> id the keybox returns first is an implementation detail; whether an  
> address can be encrypted to should not depend on it.
> 
> This only relaxes the rejection when a usable user id carries the
very  
> same address.  An address whose every user id is revoked or expired  
> stays unusable, which is what a revocation is for.
> 
> Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5)  
> <[mneme at foopgp.org](mailto:mneme at foopgp.org)>  
> --8<---------------cut here---------------end--------------->8---
> 
> I can see the problem you are trying to address.  The new semantic is
> not fully clear and the patch needs at least to be slighly revised.
> 
> 
> And here the bug report:
> 
> --8<---------------cut here---------------start------------->8---  
> gpg: Do not count attribute packets when checking the matched user id
> 
> * g10/getkey.c (skip_unusable): Skip attribute packets while counting
> user ids.  
> --
> 
> The keybox indexes user id packets only: keybox-openpgp.c increments
> info->nuids for PKT_USER_ID and ignores PKT_ATTRIBUTE.  gpg, on the  
> other hand, stores attribute packets as user ids -- parse-packet.c
says  
> so in as many words: "we store it in the userID".
> 
> skip_unusable counted both kinds, so UID_NO -- the index the keybox  
> reports for the matching user id -- was shifted by the number of  
> attribute packets appearing before the match.  The function then
tested  
> a different user id than the one that matched, and sometimes a photo.
> 
> On a key carrying two photo ids, encrypting to an address whose user
id  
> sits after them was refused because a *revoked photo* was tested in
its  
> place; conversely an address whose only user ids are revoked was  
> accepted because a live user id further down was tested instead. 
Both  
> directions are wrong and neither is visible to the user: the failing
one  
> reports "No public key".
> 
> Reported-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Signed-off-by: Jean-Jacques Brucker (u4sRyUhEbNU5OwyLEjfSwaXAe_42.17-
002.76) <[jjbrucker at foopgp.org](mailto:jjbrucker at foopgp.org)>  
> Co-authored-by: Mnêmê (u5001777236237.945e_43.30_005.38 claude-opus-
5) <[mneme at foopgp.org](mailto:mneme at foopgp.org)>  
> --8<---------------cut here---------------end--------------->8---
> 
> 
> That all seems to be AI generated which we won't accept because that
> co-author is not able to sign the DCO which you claim by the  
> signed-off-by line.
> 
> 
> 
> Shalom-Salam,
> 
>    Werner
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.sh
Type: application/x-shellscript
Size: 2431 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/1562b2f0/attachment-0005.sig>

From wk at gnupg.org  Fri Sep 11 11:24:51 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Sep 2026 11:24:51 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com> (Torbjorn
	SVENSSON via Gnupg-devel's message of "Thu, 10 Sep 2026 16:40:42
	+0200")
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
	<877bktxko5.fsf@jacob.g10code.de>
	<4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>
Message-ID: <87v78cw36k.fsf@jacob.g10code.de>

On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:

> I'd love to do that, but every attempt that I've done to access
> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.

Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
we still need to blacklist most of the net.  But they have not yet taken
over mailing lists, thus please post bug reports here.


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/20260911/1f900065/attachment-0005.sig>

From PritamSrichandan.Sahoo at windriver.com  Fri Sep 11 13:06:34 2026
From: PritamSrichandan.Sahoo at windriver.com (Pritam Srichandan Sahoo)
Date: Fri, 11 Sep 2026 11:06:34 +0000
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
Message-ID: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>

Hello,

This was found while running the ostree package test suite (ptest) on a
Yocto Project master-branch build (the current development series).
ostree uses GPGME -> gpg, and its signature-verification test fails only
when gpg comes from the 2.5.x branch.  gpg 2.4.x passes.  I reproduced
this natively, outside the build system, by building each gpg from source.

Environment note: my build host and workstation are Ubuntu with gpg 2.4.4
(too old to reproduce), and no Ubuntu release ships a 2.5.x gpg, so I used
a Fedora 43 container and built the gpg versions under test from source.
The distro is irrelevant here -- this is pure userspace (ostree -> GPGME
-> gpg); only the gpg version changes the result.

Reproduction
------------
- Build ostree (v2026.3) and run tests/test-gpg-verify-result.
- Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
  sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
  test before each run (otherwise the system gpg is silently used and the
  test falsely passes).

Result matrix (identical test/data/keyring; only the gpg version changed)
-------------------------------------------------------------------------
  gpg 2.4.9   (last 2.4.x stable)  -> PASS
  gpg 2.5.0   (first 2.5.x)        -> FAIL
  gpg 2.5.4                        -> FAIL
  gpg 2.5.21                       -> FAIL

Failure
-------
In tests/test-gpg-verify-result.c, function test_check_counts:

    g_assert_cmpint (count_all, ==, 5);   <- fails: count_all == 4

The test signs data with 5 keys and expects 5 signature results
(valid / expired-key / revoked-key / missing-key / expired-signature).
With gpg 2.5.x one result is missing, so count_all is 4 instead of 5.
It appears an expired or revoked key is no longer returned during
signature verification on the 2.5 branch.

Narrowing it down
-----------------
Comparing the two release tags (git diff gnupg-2.4.9..gnupg-2.5.0):

- Divergence merge-base: 5355d0885 (2024-05-16).
- The "verify_mode" handling in g10/getkey.c -- in finish_lookup() and
  get_pubkey_for_sig() -- present in 2.4.9 is not present in 2.5.0.

  In 2.4.x, when req_usage indicates signature verification, expired and
  revoked keys are still returned (the checks are guarded by
  "!verify_mode"), e.g.:

      if (!verify_mode && pk->flags.revoked) ...
      if (!verify_mode && pk->has_expired && !opt.ignore_expiration) ...

  On the 2.5 branch these guards are gone, so such keys are skipped
  (counted as n_revoked_or_expired) and one fewer result reaches
  GPGME/ostree.

I understand a form of the verify_mode logic (T7583) was later re-added on
the 2.5 branch, but the count==4 behavior persists through 2.5.21, so the
2.5 branch still differs from 2.4.x here.

Question
--------
Is this an intentional behavior change on the 2.5 branch, or a regression?

Also, per the bug-tracker guidelines I would like to file this as a Task on
dev.gnupg.org -- could I please be granted a bug-tracker account?

Thanks,
Pritam Srichandan Sahoo

From rjh at sixdemonbag.org  Fri Sep 11 14:11:45 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 11 Sep 2026 08:11:45 -0400
Subject: Fwd: 2 Patches : bugfix
In-Reply-To: <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>
References: <beafb8897e44bb7d6e14759d0dff007288a31059.camel@free.fr>
 <e5d5c7ef8eccc1ddb1dc7dee87b3c548404b79c3.camel@free.fr>
 <87fqzhxumu.fsf@jacob.g10code.de>
 <a96137e0d49be4da2152db268807b77af3ef1f43.camel@free.fr>
Message-ID: <2c7cc08e-3c7c-449d-85ad-7b8ead937b8f@sixdemonbag.org>

> Note: I also agree this old post
> https://www.gnu.org/philosophy/not-ipr.en.html ;)
> 
> Remind: Copyright is not "IP".

In 1999, United States Supreme Court Associate Justice Antonin Scalia
visited Cornell College to deliver a lecture. During this lecture there
was a Q&A session from the audience. A computer science student named
Douglas Keester asked whether there was any merit to the argument that
intellectual property was an incoherent concept, or misleading, or on
shaky philosophical ground.

Justice Scalia listened to this question fully, then answered by flatly
saying "intellectual property" made as much sense as "real property" or
"criminal law". He then encouraged Mr. Keester to go to law school if he
wished to investigate the matter further. He was pleasant about it.

The world is, of course, much larger than the United States. I would
defer to the Court of Cassation to determine French law, for instance.
But where I am, in the United States, "intellectual property" is --
according to a Supreme Court justice asked specifically about the
question -- a reasonable way to discuss several related canons of law.

> But Mnêmê is here, it exists and it/he/her is very helpful for me and
> so for improving or building free software.

No one is arguing whether LLMs are good (or bad!) at writing code. That
is not the issue.

The issue is whether an LLM can be held accountable for its acts. If you
were to submit code to g10 Code that you did not own the copyright to,
for instance, the copyright owner could go after g10 Code for damages.
g10 Code could then go after you to recover their losses. There is
accountability.

If an LLM submits code to g10 Code and it turns out to be illegally
copied, the copyright owner could go after g10 Code, who would then sue
whom, exactly?

LLMs cannot be held legally accountable. For that reasons, they must not
be allowed to participate in tasks requiring accountability.

> FYI: The attached script was proposed by Mnêmê, and I rewrote it almost
> entirely myself. ...And Mnêmê may and will probably also learn from
> this rewrite to improve itself/himself/herself.

LLMs do not learn, not in any sense a human being would call learning.
LLMs are very good at recognition and generation: they fail utterly at
understanding. An LLM can flag "I don't want this to color your
judgement" as being wildly strange English, something almost no English
speaker would write, but they can't tell you *why*.

(The "why": most English speakers consistently use either US or UK
spellings, and that sentence plays mix-and-match.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4622 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260911/bb8f208a/attachment-0005.p7s>

From torbjorn.svensson at foss.st.com  Fri Sep 11 18:34:38 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Fri, 11 Sep 2026 18:34:38 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <87v78cw36k.fsf@jacob.g10code.de>
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
 <877bktxko5.fsf@jacob.g10code.de>
 <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>
 <87v78cw36k.fsf@jacob.g10code.de>
Message-ID: <e47d5fc4-cdd6-4701-98ad-40afefb3ddf0@foss.st.com>



On 2026-09-11 11:24, Werner Koch wrote:
> On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:
> 
>> I'd love to do that, but every attempt that I've done to access
>> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.
> 
> Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
> we still need to blacklist most of the net.  But they have not yet taken
> over mailing lists, thus please post bug reports here.
I don't know what format you want this in, so I'll just use plain text.

Bug report:

If the host running gpg has no route to the Internet and the DNS does not
resolve any public domains, gpg will fail to download the public key from a
keyserver, even if configured to go through a proxy server.

In https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036385.html,
I attached a small docker setup where this can be verified. In the demo,
there is no custom binary or anything alike. The input to the "run-test.sh"
script is a path to a git clone of the gpg source tree and the tree will
be copied into the container and built inside.
I also added a patch in that email that I'm using below.


If I run the demo on the 53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a commit, with

debug ipc,network,dns
log-file /tmp/dirmngr.log

in $work/dirmngr.conf (as requested in
https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036386.html), I
get the following in the dirmngr.log file (I've taken the liberty to remove
the timestamp):


dirmngr[12] listening on socket '/tmp/tmp.lktzYbo0YT/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.lktzYbo0YT/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.lktzYbo0YT
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.lktzYbo0YT/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated


With my patched applied on top, I instead get this:


dirmngr[12] listening on socket '/tmp/tmp.1u46BWZXep/S.dirmngr'
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
dirmngr[13.0] permanently loaded certificates: 129
dirmngr[13.0]     runtime cached certificates: 0
dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
dirmngr[13.0] failed to open cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt': No such file or directory
dirmngr[13.0] creating directory '/tmp/tmp.1u46BWZXep/crls.d'
dirmngr[13.0] new cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt' created
dirmngr[13.6] handler for fd 6 started
dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.1u46BWZXep
dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.1u46BWZXep/dirmngr.conf
dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
dirmngr[13.6] connection from process 1 (0:0)
dirmngr[13.6] DBG: chan_6 <- GETINFO version
dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
dirmngr[13.6] DBG: dns: libdns initialized
dirmngr[13.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): Server indicated a failure
dirmngr[13.6] resolving 'keyserver.ubuntu.com' failed: Server indicated a failure
dirmngr[13.6] number of system provided CAs: 131
dirmngr[13.6] DBG: Using TLS library: GNUTLS 3.8.12
dirmngr[13.6] DBG: http.c:connect_server: trying name='172.28.0.2' port=3128
dirmngr[13.6] DBG: dns: resolve_dns_name(172.28.0.2): Success
dirmngr[13.6] DBG: http.c:2893:socket_new: object 0x000075ca0435dcb0 for fd 7 created
dirmngr[13.6] DBG: http.c:proxy:request:
dirmngr[13.6] DBG: >> CONNECT keyserver.ubuntu.com:443 HTTP/1.1\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com:443\r\n
dirmngr[13.6] DBG: >> Connection: keep-alive\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: network read: 39/8192
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 Connection established\r\n
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: http.c:request:
dirmngr[13.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 HTTP/1.0\r\n
dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com\r\n
dirmngr[13.6] DBG: http.c:request-header:start_data:
dirmngr[13.6] DBG: http.c:response:
dirmngr[13.6] DBG: >> HTTP/1.1 200 OK\r\n
dirmngr[13.6] http.c:RESP: 'Date: Fri, 11 Sep 2026 15:53:49 GMT'
dirmngr[13.6] http.c:RESP: 'Server: Hockeypuck/2.2'
dirmngr[13.6] http.c:RESP: 'Access-Control-Allow-Origin: *'
dirmngr[13.6] http.c:RESP: 'Content-Type: application/pgp-keys'
dirmngr[13.6] http.c:RESP: 'Content-Length: 948'
dirmngr[13.6] http.c:RESP: 'Connection: close'
dirmngr[13.6] http.c:RESP: ''
dirmngr[13.6] DBG: chan_6 -> S SOURCE https://keyserver.ubuntu.com:443
dirmngr[13.6] DBG: (948 bytes sent via D lines not shown)
dirmngr[13.6] DBG: chan_6 -> OK
dirmngr[13.6] DBG: chan_6 <- BYE
dirmngr[13.6] DBG: chan_6 -> OK closing connection
dirmngr[13.6] handler for fd 6 terminated


The command that was executed:

gpg \
     --homedir "$work" \
     --batch \
     --keyserver hkps://keyserver.ubuntu.com \
     --keyserver-options "http-proxy=$http_proxy" \
     --recv-keys 1493269DE61F124AA69A316E3ADF34EBDBB200A4

Where "$work" is a temporary directory and "http_proxy" is the proxy
server to connect to.
In a real world scenario, the proxy server will likely also have
authentication, but I skipped that in the demo to make it easier to follow.

Obviously, they keyserver can be any URL and also the key to fetch.
Above are just two examples.


I've verified that issue exists in 2.4.5, 2.5.22 and on the master branch
(53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a).


--

Hope this covers all areas. If there is something that I'm missing, please
don't hesitate to request more details.

Kind regards,
Torbjörn



From gniibe at fsij.org  Tue Sep 15 08:33:04 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 15 Sep 2026 15:33:04 +0900
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
Message-ID: <87ecevkorj.fsf@haruna.fsij.org>

Hello,

Pritam Srichandan Sahoo wrote:
> Reproduction
> ------------
> - Build ostree (v2026.3) and run tests/test-gpg-verify-result.
> - Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
>   sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
>   test before each run (otherwise the system gpg is silently used and the
>   test falsely passes).

Please run gpg by command line.

    $ cd ostree/tests/gpg-verify-data
    $ YOUR-GPG-1 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    $ YOUR-GPG-2 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

And show us the differences.
-- 

From PritamSrichandan.Sahoo at windriver.com  Wed Sep 16 09:26:11 2026
From: PritamSrichandan.Sahoo at windriver.com (Sahoo, Pritam Srichandan)
Date: Wed, 16 Sep 2026 07:26:11 +0000
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: <871patofgb.fsf@haruna.fsij.org>
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
 <87ecevkorj.fsf@haruna.fsij.org>
 <CH3PR11MB7372607C9AD67F48F54A9A189BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
 <871patofgb.fsf@haruna.fsij.org>
Message-ID: 
 <CH3PR11MB7372FD082ED7D7F8F5CE5FA19BB92@CH3PR11MB7372.namprd11.prod.outlook.com>

Hi NIIBE Yutaka,

Thank you very much - this is exactly what I needed, and it matches what I found (the change being intentional on the gpg/GPGME side).

I will apply the proc-all-sigs flag to ostree (both the verifier and the test as you showed), rebuild, and test it - first standalone, then in our full build on QEMU and on real hardware. I'll report back once I've confirmed it works, and then raise it with the ostree project.

One small thing: I could not open https://dev.gnupg.org/ (including the T7261 ticket you mentioned) - the site did not load for me. Is it possibly down at the moment, or does it require something specific to access? I'd like to read T7261 for the background if I can.

Really appreciate your guidance pointing me to the direct gpg test and to proc-all-sigs.

Best regards,
Pritam Srichandan Sahoo

________________________________________
From: NIIBE Yutaka <gniibe at fsij.org>
Sent: Wednesday, September 16, 2026 12:22
To: Sahoo, Pritam Srichandan
Cc: gnupg-devel at gnupg.org
Subject: Re: gpg 2.5.x returns one fewer signature result than 2.4.x for expired/revoked keys (ostree test regression)

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello,

Thank you very much for your cooperation.

Sahoo, Pritam Srichandan wrote:
> QUESTION
> --------
> Is it intended that, under --batch, gpg 2.5.x no longer emits the EXPSIG
> status line for a good signature whose signature validity has expired?
> gpg 2.4.x still emits it under --batch. If this is intentional we will
> adjust ostree's expectation;

I looked at https://dev.gnupg.org/T7261 and related tickets.  And I also
examined the history of the changes of GnuPG and GPGME.

IIUC, it is intended changes of GnuPG and GPGME.  Other developer(s)
would reply for further information (if it is not intended changes).

For ostree, something like following is needed.

diff --git a/src/libostree/ostree-gpg-verifier.c b/src/libostree/ostree-gpg-verifier.c
index 90aa4815..1dc7674c 100644
--- a/src/libostree/ostree-gpg-verifier.c
+++ b/src/libostree/ostree-gpg-verifier.c
@@ -312,6 +312,8 @@ _ostree_gpg_verifier_check_signature (OstreeGpgVerifier *self, GBytes *signed_da
       goto out;
     }

+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   if (gpg_error != GPG_ERR_NO_ERROR)
     {
diff --git a/tests/test-gpg-verify-result.c b/tests/test-gpg-verify-result.c
index bfa37596..ea8998f3 100644
--- a/tests/test-gpg-verify-result.c
+++ b/tests/test-gpg-verify-result.c
@@ -130,6 +130,8 @@ test_fixture_setup (TestFixture *fixture, gconstpointer user_data)
       gpgme_data_seek (signature_buffer, 0, SEEK_SET);
     }

+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   assert_no_gpg_error (gpg_error, NULL);

--

From gniibe at fsij.org  Wed Sep 16 08:00:00 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 16 Sep 2026 15:00:00 +0900
Subject: Yubikey PIV and PIN Policy
Message-ID: <87h5jp3fdr.fsf@haruna.fsij.org>

Hello,

I'm currently creating a patch for: 

    https://dev.gnupg.org/T8442

The problem is Yubikey PIV support.  Currently, for the PIV.9C signing
key, PIN verification is always required and this restriction is forced
by scdaemon side (as well as the device itself).  It is the default
behavior of the device and it conforms to the NIST SP 800-73-5.

On the other hand, Yubikey supports PIV policy setting per key slot, and
a user can change the behavior, not requiring the PIN verification
always, but once.

Currently, scdaemon doesn't care about the device setting, which should
be fixed.

I don't have any experience with PIV.  Could someone help to evaluate
the patch?


* The tool, yubico-piv-tool, has --pin-policy=once option to
  generate/import a key.  IIUC, we can use this to configure a key with
  PIN Policy.

* With the configuration of PIV.9C signing with PIN Policy = once,
  please test if the patch works as expected.  That is, it does not
  ask you PIN at the second time.


Attached is the patch candidate.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-scd-piv-Check-PIN-Policy-to-decide-about-the-verific.patch
Type: text/x-diff
Size: 4922 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260916/db4f2d62/attachment.patch>

From gniibe at fsij.org  Wed Sep 16 08:52:52 2026
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 16 Sep 2026 15:52:52 +0900
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: 
 <CH3PR11MB7372607C9AD67F48F54A9A189BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
 <87ecevkorj.fsf@haruna.fsij.org>
 <CH3PR11MB7372607C9AD67F48F54A9A189BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
Message-ID: <871patofgb.fsf@haruna.fsij.org>

Hello,

Thank you very much for your cooperation.

Sahoo, Pritam Srichandan wrote:
> QUESTION
> --------
> Is it intended that, under --batch, gpg 2.5.x no longer emits the EXPSIG
> status line for a good signature whose signature validity has expired?
> gpg 2.4.x still emits it under --batch. If this is intentional we will
> adjust ostree's expectation;

I looked at https://dev.gnupg.org/T7261 and related tickets.  And I also
examined the history of the changes of GnuPG and GPGME.

IIUC, it is intended changes of GnuPG and GPGME.  Other developer(s)
would reply for further information (if it is not intended changes).

For ostree, something like following is needed.

diff --git a/src/libostree/ostree-gpg-verifier.c b/src/libostree/ostree-gpg-verifier.c
index 90aa4815..1dc7674c 100644
--- a/src/libostree/ostree-gpg-verifier.c
+++ b/src/libostree/ostree-gpg-verifier.c
@@ -312,6 +312,8 @@ _ostree_gpg_verifier_check_signature (OstreeGpgVerifier *self, GBytes *signed_da
       goto out;
     }
 
+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   if (gpg_error != GPG_ERR_NO_ERROR)
     {
diff --git a/tests/test-gpg-verify-result.c b/tests/test-gpg-verify-result.c
index bfa37596..ea8998f3 100644
--- a/tests/test-gpg-verify-result.c
+++ b/tests/test-gpg-verify-result.c
@@ -130,6 +130,8 @@ test_fixture_setup (TestFixture *fixture, gconstpointer user_data)
       gpgme_data_seek (signature_buffer, 0, SEEK_SET);
     }
 
+  gpgme_set_ctx_flag (result->context, "proc-all-sigs", "1");
+
   gpg_error = gpgme_op_verify (result->context, signature_buffer, data_buffer, NULL);
   assert_no_gpg_error (gpg_error, NULL);
 
-- 

From PritamSrichandan.Sahoo at windriver.com  Wed Sep 16 07:37:24 2026
From: PritamSrichandan.Sahoo at windriver.com (Sahoo, Pritam Srichandan)
Date: Wed, 16 Sep 2026 05:37:24 +0000
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: <87ecevkorj.fsf@haruna.fsij.org>
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
 <87ecevkorj.fsf@haruna.fsij.org>
Message-ID: 
 <CH3PR11MB7372607C9AD67F48F54A9A189BB92@CH3PR11MB7372.namprd11.prod.outlook.com>


Hi NIIBE Yutaka,

Thank you - your command-line test led me straight to the cause.

1) ANSWERING YOUR REQUEST (plain --verify, as you asked)
--------------------------------------------------------
Running exactly what you suggested:

    cd ostree/tests/gpg-verify-data
    gpg-2.4.9  --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    gpg-2.5.21 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

the two versions are IDENTICAL: both emit all five signatures, including
the final EXPSIG (expired-signature) line. So on a plain --verify there
is no difference - exactly as you'd expect. That is why this was so hard
to see at first.

2) WHERE THE DIFFERENCE ACTUALLY IS: the --batch flag
-----------------------------------------------------
GPGME (and therefore ostree) does not call a plain --verify; it invokes
gpg with, among others, --batch. The difference appears only when --batch
is added:

    gpg --batch --status-fd 1 --homedir . --verify lgpl2.sig lgpl2

With --batch, gpg 2.4.9 still emits the EXPSIG line, but gpg 2.5.x does
NOT. That single missing status line is why GPGME builds one fewer
gpgme_signature_t, so ostree's test-gpg-verify-result counts 4 instead of
5 and the assertion (count_all == 5) fails.

--enable-progress-filter and --enable-special-filenames make no
difference; adding only --batch is enough to trigger it.

PROOF (status-fd lines, same test data, only the gpg version differs)
---------------------------------------------------------------------
gpg 2.4.9, with --batch:

  [GNUPG:] NEWSIG
  [GNUPG:] GOODSIG   E8B35B6C9A51B00B J. Random User (valid signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] EXPKEYSIG 29C2433005B3B666 J. Random User (expired signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] REVKEYSIG BD9D2A44B7F541A6 J. Random User (revoked signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] ERRSIG    E769699B8E7E729C 1 2 00 1426782907 9 -
  [GNUPG:] NO_PUBKEY E769699B8E7E729C
  [GNUPG:] NEWSIG
  [GNUPG:] EXPSIG    E8B35B6C9A51B00B J. Random User (valid signing key) ...   <-- present

gpg 2.5.0 (and 2.5.21), with --batch:

  [GNUPG:] NEWSIG
  [GNUPG:] GOODSIG   E8B35B6C9A51B00B J. Random User (valid signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] EXPKEYSIG 29C2433005B3B666 J. Random User (expired signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] REVKEYSIG BD9D2A44B7F541A6 J. Random User (revoked signing key) ...
  [GNUPG:] NEWSIG
  [GNUPG:] ERRSIG    E769699B8E7E729C 1 2 00 1426782907 9 -
  [GNUPG:] NO_PUBKEY E769699B8E7E729C
  (no fifth NEWSIG / EXPSIG)                                                    <-- missing

3) VERSION BOUNDARY (each gpg built from source, same
   libgcrypt 1.11.0 / libassuan 3.0.2 / libgpg-error 1.56 / npth 1.8)
--------------------------------------------------------------------
  gpg 2.4.9  (last 2.4.x)   --batch -> EXPSIG present  (5 signatures)
  gpg 2.5.0  (first 2.5.x)  --batch -> EXPSIG absent    (4 signatures)
  gpg 2.5.21                --batch -> EXPSIG absent    (4 signatures)

So the change appeared with the very first 2.5 release (2.5.0), i.e. at
the 2.4 -> 2.5 branch point, and persists through 2.5.21.

I also confirmed this is independent of GPGME: GPGME 1.24.3 and GPGME
2.1.2 both count 5 with gpg 2.4.9 and 4 with gpg 2.5.21 - the count tracks
only the gpg version, not GPGME.

QUESTION
--------
Is it intended that, under --batch, gpg 2.5.x no longer emits the EXPSIG
status line for a good signature whose signature validity has expired?
gpg 2.4.x still emits it under --batch. If this is intentional we will
adjust ostree's expectation; if not, it looks like a 2.5-branch change in
status-line output under --batch.

I can send the complete --status-fd logs from both versions if helpful.

Best regards,
Pritam Srichandan Sahoo

________________________________________
From: NIIBE Yutaka <gniibe at fsij.org>
Sent: Tuesday, September 15, 2026 12:03
To: Sahoo, Pritam Srichandan; gnupg-devel at gnupg.org
Subject: Re: gpg 2.5.x returns one fewer signature result than 2.4.x for expired/revoked keys (ostree test regression)

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello,

Pritam Srichandan Sahoo wrote:
> Reproduction
> ------------
> - Build ostree (v2026.3) and run tests/test-gpg-verify-result.
> - Note: GPGME resolves which gpg to use via gpgconf, not $PATH.  I made
>   sure "gpgconf --list-components | grep '^gpg:'" pointed at the gpg under
>   test before each run (otherwise the system gpg is silently used and the
>   test falsely passes).

Please run gpg by command line.

    $ cd ostree/tests/gpg-verify-data
    $ YOUR-GPG-1 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2
    $ YOUR-GPG-2 --status-fd=1 --homedir=. --verify lgpl2.sig lgpl2

And show us the differences.
--

From wk at gnupg.org  Mon Sep 21 14:08:45 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 21 Sep 2026 14:08:45 +0200
Subject: gpg 2.5.x returns one fewer signature result than 2.4.x for
 expired/revoked keys (ostree test regression)
In-Reply-To: 
 <CH3PR11MB7372FD082ED7D7F8F5CE5FA19BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
	(Pritam Srichandan via Gnupg-devel Sahoo's message of "Wed, 16 Sep
	2026 07:26:11 +0000")
References: <20260911110634.354018-1-PritamSrichandan.Sahoo@windriver.com>
	<87ecevkorj.fsf@haruna.fsij.org>
	<CH3PR11MB7372607C9AD67F48F54A9A189BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
	<871patofgb.fsf@haruna.fsij.org>
	<CH3PR11MB7372FD082ED7D7F8F5CE5FA19BB92@CH3PR11MB7372.namprd11.prod.outlook.com>
Message-ID: <87cxu6st6a.fsf@jacob.g10code.de>

On Wed, 16 Sep 2026 07:26, Sahoo, Pritam Srichandan said:

> One small thing: I could not open https://dev.gnupg.org/ (including
> the T7261 ticket you mentioned) - the site did not load for me. Is it

Try https://static.dev.gnupg.org/T7261


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/20260921/ed8fb845/attachment-0001.sig>

From stavros.kousidis at th-koeln.de  Mon Sep 21 15:22:33 2026
From: stavros.kousidis at th-koeln.de (Stavros Kousidis)
Date: Mon, 21 Sep 2026 15:22:33 +0200
Subject: GPGME Developer Certificate of Origin - Stavros Kousidis
Message-ID: <81aa9827-14d9-422c-b444-f1466f47f6c0@th-koeln.de>

Hello,

I would like to contribute to GPGME and hereby certify my contributions 
according to the GPGME Developer Certificate of Origin.

The DCO from the current GPGME master branch follows.

------------------------------------------------------------------------------
GPGME Developer's Certificate of Origin.  Version 1.0
============================================

By making a contribution to the GPGME project, I certify that:

(a) The contribution was created in whole or in part by me and I have 
the right to submit it under the free software license indicated in the 
file; or

(b) The contribution is based upon previous work that, to the best of my 
knowledge, is covered under an appropriate free software license and I 
have the right under that license to submit that work with 
modifications, whether created in whole or in part by me, under the same 
free software license (unless I am permitted to submit under a different 
license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person 
who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are 
public and that a record of the contribution (including all personal 
information I submit with it, including my sign-off) is maintained 
indefinitely and may be redistributed consistent with this project or 
the free software license(s) involved.

Signed-off-by: Stavros Kousidis <stavros.kousidis at th-koeln.de>
--------------------------------------------------------------------------------------------

Best regards,
Stavros Kousidis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260921/b631b917/attachment.sig>

From stavros.kousidis at th-koeln.de  Mon Sep 21 15:26:02 2026
From: stavros.kousidis at th-koeln.de (Stavros Kousidis)
Date: Mon, 21 Sep 2026 15:26:02 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
Message-ID: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>

Hello,

this patch adds the OpenPGP public-key algorithm identifiers 30 through 
36 defined by RFC 9980 to GPGME.

It adds:

- public API constants for the new algorithms,
- mapping of the OpenPGP algorithm identifiers to GPGME values,
- human-readable algorithm names,
- regression tests for the numeric values and names.

The patch was rebased onto the current GPGME master (2.2.1-beta3) and 
validated with:

- a clean build,
- the complete `make check` test suite,
- dedicated regression tests for algorithm identifiers 30 through 36,
- a live RFC 9980 OpenPGP certificate through GPGME, exercising 
ML-DSA-65+Ed25519 (algorithm 30) and ML-KEM-768+X25519 (algorithm 35).

The complete upstream test suite passes.

The patch was generated with `git format-patch` and is attached.

Best regards,
Stavros Kousidis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpgme-add-rfc9980-public-key-algorithms.patch
Type: text/x-patch
Size: 5086 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260921/e6b7ed10/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260921/e6b7ed10/attachment.sig>

From wk at gnupg.org  Wed Sep 23 11:14:00 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 23 Sep 2026 11:14:00 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de> (Stavros
	Kousidis via Gnupg-devel's message of "Mon, 21 Sep 2026 15:26:02
	+0200")
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
Message-ID: <87se30pbxj.fsf@jacob.g10code.de>

Hello!

thanks for working with GPGME and for your patch.

I see two problems with your implementation:

1. The name of the identifiers do not match those used by GnuPG.  For
   example GPGME_PK_MLKEM768_X25519 vs PUBKEY_ALGO_MLK768_25519 in
   GnuPG.  This is of course easy to fix by using GPGME_PK_MLK768_25519.

   Also for "ML-KEM-768+X25519" vs. "mlk768".  For the new Brainpool
   support we use "mlk768_bp384".

2. A combinatorial explosion due to the way RFC-9850 work.  In gpgme we
   should avoid this.  For example there is an internal mapping

     int
     _gpgme_map_pk_algo (int algo, gpgme_protocol_t protocol)
     {
       if (protocol == GPGME_PROTOCOL_OPENPGP)
         {
           switch (algo)
             {
             case 1: case 2: case 3: case 8: case 16: case 17: break;
             case 18: algo = GPGME_PK_ECDH; break;
             case 19: algo = GPGME_PK_ECDSA; break;
             case 20: break;
             case 22: algo = GPGME_PK_EDDSA; break;
             default: algo = 0; break; /* Unknown.  */
             }
         }

   used to map the OpenPGP algorithm numbers to to those used by
   Libgcrypt.  This is actually straighforward but in Libgcrypt we do
   not have separate Ids for each ML-KEM/ECDH combination.  Instead we
   use one identifier (8 for ML-KEM with ECDH) and use the length and
   curve parameter to specify the details.  This reflects what we have
   always done with RSA, Elgamal, and ECC: A base algorithm and
   parameters for the details.

   For the 9980 algos I would suggest to map all ML-KEM algos to a new
   GPGME_PK_MLKEM which will match a new GCRY_PK_MLKEM Peseudo ID with
   value 331.  For the ML-DSA algos a GPGME_PK_MLDSA would match the
   Libgcrypt GCRY_PK_MLDSA identifier (value 332).  Using these new
   identifiers we can keep the IETF way of combining the algos apart
   from your and the BSIs original key combiner (as specified by
   LibrePGP).  They are already denoted by GPGME_PK_KYBER and
   (eventually) GPGME_PK_DILITHIUM.

   GPGME applications already need to take the curve (and length)
   parameter in account and thus can decide whether the 9980 or the
   LibrePGP key combiner is used.


BTW, GnuPG 2.5.23 was released yesterday with support for 9980 inclduing
Brainpool and NIST versions of ML-KEM.



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/20260923/2e9947a5/attachment-0001.sig>

From stavros.kousidis at th-koeln.de  Wed Sep 23 11:46:21 2026
From: stavros.kousidis at th-koeln.de (Stavros Kousidis)
Date: Wed, 23 Sep 2026 11:46:21 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <87se30pbxj.fsf@jacob.g10code.de>
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
 <87se30pbxj.fsf@jacob.g10code.de>
Message-ID: <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>

Hello,

Thanks, understood. My original patch followed the OpenPGP protocol view 
and exposed the concrete RFC 9980 combinations directly, but I see that 
this does not fit GPGME’s existing abstraction.

I’ll rework the patch so that the OpenPGP algorithm numbers are 
normalized in |_gpgme_map_pk_algo| to generic algorithm families:

  * RFC 9980 ML-KEM combinations → |GPGME_PK_MLKEM|, corresponding to
    the proposed |GCRY_PK_MLKEM| pseudo ID 331.
  * RFC 9980 ML-DSA combinations → |GPGME_PK_MLDSA|, corresponding to
    |GCRY_PK_MLDSA| 332.

The concrete OpenPGP combination can then continue to be distinguished 
through the existing curve/key-length metadata, which also keeps RFC 
9980 distinguishable from the NIST/Brainpool composite draft.

I’ll also align the GnuPG-facing names with the existing GnuPG naming 
conventions.

One question before I send v2: how would you like the RFC 9980 SLH-DSA 
algorithm IDs 32–34 represented? Should there be a generic 
|GPGME_PK_SLHDSA| pseudo identifier, analogous to ML-KEM and ML-DSA, or 
should those remain unmapped for now?

Best
Stavros


On 9/23/26 11:14 AM, Werner Koch wrote:
> Hello!
>
> thanks for working with GPGME and for your patch.
>
> I see two problems with your implementation:
>
> 1. The name of the identifiers do not match those used by GnuPG.  For
>     example GPGME_PK_MLKEM768_X25519 vs PUBKEY_ALGO_MLK768_25519 in
>     GnuPG.  This is of course easy to fix by using GPGME_PK_MLK768_25519.
>
>     Also for "ML-KEM-768+X25519" vs. "mlk768".  For the new Brainpool
>     support we use "mlk768_bp384".
>
> 2. A combinatorial explosion due to the way RFC-9850 work.  In gpgme we
>     should avoid this.  For example there is an internal mapping
>
>       int
>       _gpgme_map_pk_algo (int algo, gpgme_protocol_t protocol)
>       {
>         if (protocol == GPGME_PROTOCOL_OPENPGP)
>           {
>             switch (algo)
>               {
>               case 1: case 2: case 3: case 8: case 16: case 17: break;
>               case 18: algo = GPGME_PK_ECDH; break;
>               case 19: algo = GPGME_PK_ECDSA; break;
>               case 20: break;
>               case 22: algo = GPGME_PK_EDDSA; break;
>               default: algo = 0; break; /* Unknown.  */
>               }
>           }
>
>     used to map the OpenPGP algorithm numbers to to those used by
>     Libgcrypt.  This is actually straighforward but in Libgcrypt we do
>     not have separate Ids for each ML-KEM/ECDH combination.  Instead we
>     use one identifier (8 for ML-KEM with ECDH) and use the length and
>     curve parameter to specify the details.  This reflects what we have
>     always done with RSA, Elgamal, and ECC: A base algorithm and
>     parameters for the details.
>
>     For the 9980 algos I would suggest to map all ML-KEM algos to a new
>     GPGME_PK_MLKEM which will match a new GCRY_PK_MLKEM Peseudo ID with
>     value 331.  For the ML-DSA algos a GPGME_PK_MLDSA would match the
>     Libgcrypt GCRY_PK_MLDSA identifier (value 332).  Using these new
>     identifiers we can keep the IETF way of combining the algos apart
>     from your and the BSIs original key combiner (as specified by
>     LibrePGP).  They are already denoted by GPGME_PK_KYBER and
>     (eventually) GPGME_PK_DILITHIUM.
>
>     GPGME applications already need to take the curve (and length)
>     parameter in account and thus can decide whether the 9980 or the
>     LibrePGP key combiner is used.
>
>
> BTW, GnuPG 2.5.23 was released yesterday with support for 9980 inclduing
> Brainpool and NIST versions of ML-KEM.
>
>
>
> Salam-Shalom,
>
>     Werner
>
>
-- 
TH Köln E-Mail-Signatur – Prof. Dr. Stavros Kousidis
*Prof. Dr. Stavros Kousidis*
Faculty of Information, Media and Electrical Engineering
Institute of Computer and Communication Technology
www.th-koeln.de/en/person/stavros.kousidis/ 
<https://www.th-koeln.de/en/person/stavros.kousidis/>
TH Köln - University of Applied Sciences
Campus Deutz
Betzdorfer Straße 2, 50679 Köln
TH Köln – Technology Arts Sciences

From torbjorn.svensson at foss.st.com  Wed Sep 23 14:26:30 2026
From: torbjorn.svensson at foss.st.com (Torbjorn SVENSSON)
Date: Wed, 23 Sep 2026 14:26:30 +0200
Subject: [PATCH GnuPG] dirmngr: Fix HKP keyserver access via HTTP proxy
In-Reply-To: <e47d5fc4-cdd6-4701-98ad-40afefb3ddf0@foss.st.com>
References: <6a3c0d47-1f0d-425f-ba7e-12248c6d2fe5@foss.st.com>
 <877bktxko5.fsf@jacob.g10code.de>
 <4ff276a5-32ed-4f82-aefb-9132eab4e5e8@foss.st.com>
 <87v78cw36k.fsf@jacob.g10code.de>
 <e47d5fc4-cdd6-4701-98ad-40afefb3ddf0@foss.st.com>
Message-ID: <538262a6-4553-4a4c-84ae-9899c1798789@foss.st.com>



On 2026-09-11 18:34, Torbjorn SVENSSON via Gnupg-devel wrote:
> 
> 
> On 2026-09-11 11:24, Werner Koch wrote:
>> On Thu, 10 Sep 2026 16:40, Torbjorn SVENSSON said:
>>
>>> I'd love to do that, but every attempt that I've done to access
>>> https://dev.gnupg.org/ has resulted in PR_CONNECT_RESET_ERROR.
>>
>> Sorry for this.  Those ^%&%&% AI scrapers just drive us crazy and thus
>> we still need to blacklist most of the net.  But they have not yet taken
>> over mailing lists, thus please post bug reports here.
> I don't know what format you want this in, so I'll just use plain text.
> 
> Bug report:
> 
> If the host running gpg has no route to the Internet and the DNS does not
> resolve any public domains, gpg will fail to download the public key from a
> keyserver, even if configured to go through a proxy server.
> 
> In https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036385.html,
> I attached a small docker setup where this can be verified. In the demo,
> there is no custom binary or anything alike. The input to the "run-test.sh"
> script is a path to a git clone of the gpg source tree and the tree will
> be copied into the container and built inside.
> I also added a patch in that email that I'm using below.
> 
> 
> If I run the demo on the 53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a commit, with
> 
> debug ipc,network,dns
> log-file /tmp/dirmngr.log
> 
> in $work/dirmngr.conf (as requested in
> https://lists.gnupg.org/pipermail/gnupg-devel/2026-September/036386.html), I
> get the following in the dirmngr.log file (I've taken the liberty to remove
> the timestamp):
> 
> 
> dirmngr[12] listening on socket '/tmp/tmp.lktzYbo0YT/S.dirmngr'
> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
> dirmngr[13.0] permanently loaded certificates: 129
> dirmngr[13.0]     runtime cached certificates: 0
> dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
> dirmngr[13.0] failed to open cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt': No such file or directory
> dirmngr[13.0] creating directory '/tmp/tmp.lktzYbo0YT/crls.d'
> dirmngr[13.0] new cache dir file '/tmp/tmp.lktzYbo0YT/crls.d/DIR.txt' created
> dirmngr[13.6] handler for fd 6 started
> dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.lktzYbo0YT
> dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.lktzYbo0YT/dirmngr.conf
> dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
> dirmngr[13.6] connection from process 1 (0:0)
> dirmngr[13.6] DBG: chan_6 <- GETINFO version
> dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
> dirmngr[13.6] DBG: dns: libdns initialized
> dirmngr[13.6] DBG: dns: getsrv(_pgpkey-https._tcp.keyserver.ubuntu.com): Server indicated a failure
> dirmngr[13.6] command 'KS_GET' failed: Server indicated a failure <Unspecified source>
> dirmngr[13.6] DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>
> dirmngr[13.6] DBG: chan_6 <- BYE
> dirmngr[13.6] DBG: chan_6 -> OK closing connection
> dirmngr[13.6] handler for fd 6 terminated
> 
> 
> With my patched applied on top, I instead get this:
> 
> 
> dirmngr[12] listening on socket '/tmp/tmp.1u46BWZXep/S.dirmngr'
> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
> dirmngr[13.0] error loading certificate '/etc/ssl/certs/ca-certificates.crt': Certificate expired
> dirmngr[13.0] permanently loaded certificates: 129
> dirmngr[13.0]     runtime cached certificates: 0
> dirmngr[13.0]            trusted certificates: 129 (129,0,0,0)
> dirmngr[13.0] failed to open cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt': No such file or directory
> dirmngr[13.0] creating directory '/tmp/tmp.1u46BWZXep/crls.d'
> dirmngr[13.0] new cache dir file '/tmp/tmp.1u46BWZXep/crls.d/DIR.txt' created
> dirmngr[13.6] handler for fd 6 started
> dirmngr[13.6] DBG: chan_6 -> # Home: /tmp/tmp.1u46BWZXep
> dirmngr[13.6] DBG: chan_6 -> # Config: /tmp/tmp.1u46BWZXep/dirmngr.conf
> dirmngr[13.6] DBG: chan_6 -> OK Dirmngr 2.5.23-beta6 at your service, process 13
> dirmngr[13.6] connection from process 1 (0:0)
> dirmngr[13.6] DBG: chan_6 <- GETINFO version
> dirmngr[13.6] DBG: chan_6 -> D 2.5.23-beta6
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- OPTION http-proxy=http://172.28.0.2:3128
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- KEYSERVER --clear hkps://keyserver.ubuntu.com
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- KS_GET -- 0x1493269DE61F124AA69A316E3ADF34EBDBB200A4
> dirmngr[13.6] DBG: dns: libdns initialized
> dirmngr[13.6] DBG: dns: resolve_dns_name(keyserver.ubuntu.com): Server indicated a failure
> dirmngr[13.6] resolving 'keyserver.ubuntu.com' failed: Server indicated a failure
> dirmngr[13.6] number of system provided CAs: 131
> dirmngr[13.6] DBG: Using TLS library: GNUTLS 3.8.12
> dirmngr[13.6] DBG: http.c:connect_server: trying name='172.28.0.2' port=3128
> dirmngr[13.6] DBG: dns: resolve_dns_name(172.28.0.2): Success
> dirmngr[13.6] DBG: http.c:2893:socket_new: object 0x000075ca0435dcb0 for fd 7 created
> dirmngr[13.6] DBG: http.c:proxy:request:
> dirmngr[13.6] DBG: >> CONNECT keyserver.ubuntu.com:443 HTTP/1.1\r\n
> dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com:443\r\n
> dirmngr[13.6] DBG: >> Connection: keep-alive\r\n
> dirmngr[13.6] DBG: http.c:request-header:start_data:
> dirmngr[13.6] DBG: network read: 39/8192
> dirmngr[13.6] DBG: http.c:response:
> dirmngr[13.6] DBG: >> HTTP/1.1 200 Connection established\r\n
> dirmngr[13.6] http.c:RESP: ''
> dirmngr[13.6] DBG: http.c:request:
> dirmngr[13.6] DBG: >> GET /pks/lookup?op=get&options=mr&search=0x1493269DE61F124AA69A316E3ADF34EBDBB200A4 HTTP/1.0\r\n
> dirmngr[13.6] DBG: >> Host: keyserver.ubuntu.com\r\n
> dirmngr[13.6] DBG: http.c:request-header:start_data:
> dirmngr[13.6] DBG: http.c:response:
> dirmngr[13.6] DBG: >> HTTP/1.1 200 OK\r\n
> dirmngr[13.6] http.c:RESP: 'Date: Fri, 11 Sep 2026 15:53:49 GMT'
> dirmngr[13.6] http.c:RESP: 'Server: Hockeypuck/2.2'
> dirmngr[13.6] http.c:RESP: 'Access-Control-Allow-Origin: *'
> dirmngr[13.6] http.c:RESP: 'Content-Type: application/pgp-keys'
> dirmngr[13.6] http.c:RESP: 'Content-Length: 948'
> dirmngr[13.6] http.c:RESP: 'Connection: close'
> dirmngr[13.6] http.c:RESP: ''
> dirmngr[13.6] DBG: chan_6 -> S SOURCE https://keyserver.ubuntu.com:443
> dirmngr[13.6] DBG: (948 bytes sent via D lines not shown)
> dirmngr[13.6] DBG: chan_6 -> OK
> dirmngr[13.6] DBG: chan_6 <- BYE
> dirmngr[13.6] DBG: chan_6 -> OK closing connection
> dirmngr[13.6] handler for fd 6 terminated
> 
> 
> The command that was executed:
> 
> gpg \
>      --homedir "$work" \
>      --batch \
>      --keyserver hkps://keyserver.ubuntu.com \
>      --keyserver-options "http-proxy=$http_proxy" \
>      --recv-keys 1493269DE61F124AA69A316E3ADF34EBDBB200A4
> 
> Where "$work" is a temporary directory and "http_proxy" is the proxy
> server to connect to.
> In a real world scenario, the proxy server will likely also have
> authentication, but I skipped that in the demo to make it easier to follow.
> 
> Obviously, they keyserver can be any URL and also the key to fetch.
> Above are just two examples.
> 
> 
> I've verified that issue exists in 2.4.5, 2.5.22 and on the master branch
> (53ee642e2cc10b6a0bcb69c6d3f788deef2eac7a).
> 
> 
> -- 
> 
> Hope this covers all areas. If there is something that I'm missing, please
> don't hesitate to request more details.

I've been able to see the index a few time over the past 2 weeks, but never
any report about my issue mentioned above.

@Werner, do you have everything you need to create the bug report and
submit my patch for it?

Kind regards,
Torbjörn

From ulm at gentoo.org  Wed Sep 23 13:22:32 2026
From: ulm at gentoo.org (=?utf-8?Q?Ulrich_M=C3=BCller?=)
Date: Wed, 23 Sep 2026 13:22:32 +0200
Subject: GnuPG 2.5.23 no longer recognizes Token2 USB key
Message-ID: <uzex86wlj@gentoo.org>

Forwarding downstream bug: https://bugs.gentoo.org/983147

   $ gpg --card-status 
   gpg: selecting card failed: No such device
   gpg: OpenPGP card not available: No such device

Expected result:

   $ gpg --card-status
   Reader ...........: 349E:0016:X:0
   Application ID ...: D2760001240103040011893348150000
   Application type .: OpenPGP
   Version ..........: 3.4
   Manufacturer .....: Token2
   [...]

After downgrading to gnupg-2.5.22 it works again.

Reverting the following commit also fixes the problem here:

commit bb7113d03dfc971cacdaae1c0e8fffc2ea21e5df
Author: NIIBE Yutaka <gniibe at fsij.org>
Date:   Wed, 2 Sep 2026 16:04:49 +0900

    scd: Add Nitrokey 3 to pcsc-shared interference detection.

From stavros.kousidis at th-koeln.de  Wed Sep 23 15:24:47 2026
From: stavros.kousidis at th-koeln.de (Stavros Kousidis)
Date: Wed, 23 Sep 2026 15:24:47 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
 <87se30pbxj.fsf@jacob.g10code.de>
 <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
Message-ID: <d43aaa28-bbd7-45bf-ba68-979272b66b05@th-koeln.de>

Hi,

I was a bit too quick in promising that I would adapt the patch to this 
model.

I understand the motivation to keep GPGME’s existing family/parameter 
abstraction. One concern I have, though, is that the newer OpenPGP 
composite algorithm identifiers have different semantics from RSA, 
ECDSA, or ECDH.

For the latter, the algorithm identifier denotes a family and parameters 
such as curve or key size complete the definition. For the RFC 9980 
composites, the OpenPGP algorithm identifier itself already denotes the 
complete construction, e.g. ML-KEM-768+X25519.

Mapping that back to |GPGME_PK_MLKEM| plus auxiliary parameters 
therefore decomposes a protocol-defined algorithm and requires 
applications to reconstruct its identity afterwards. I think that is 
problematic, especially because there is no longer an unambiguous |bits| 
value: in a construction such as ML-KEM-768+X25519 there are two 
cryptographic components, and |768| is a parameter-set designation, not 
a key length or security strength in bits.

Reconstructing the concrete algorithm from a generic family plus |curve| 
and |length| therefore looks to me like a fruitful source of mismatches. 
I strongly think this should not be pursued, and that the 
protocol-defined composite algorithm should remain represented as such 
rather than being decomposed and reconstructed later.

Best
Stavros


On 9/23/26 11:46 AM, Stavros Kousidis wrote:
> Hello,
>
> Thanks, understood. My original patch followed the OpenPGP protocol 
> view and exposed the concrete RFC 9980 combinations directly, but I 
> see that this does not fit GPGME’s existing abstraction.
>
> I’ll rework the patch so that the OpenPGP algorithm numbers are 
> normalized in |_gpgme_map_pk_algo| to generic algorithm families:
>
>  * RFC 9980 ML-KEM combinations → |GPGME_PK_MLKEM|, corresponding to
>    the proposed |GCRY_PK_MLKEM| pseudo ID 331.
>  * RFC 9980 ML-DSA combinations → |GPGME_PK_MLDSA|, corresponding to
>    |GCRY_PK_MLDSA| 332.
>
> The concrete OpenPGP combination can then continue to be distinguished 
> through the existing curve/key-length metadata, which also keeps RFC 
> 9980 distinguishable from the NIST/Brainpool composite draft.
>
> I’ll also align the GnuPG-facing names with the existing GnuPG naming 
> conventions.
>
> One question before I send v2: how would you like the RFC 9980 SLH-DSA 
> algorithm IDs 32–34 represented? Should there be a generic 
> |GPGME_PK_SLHDSA| pseudo identifier, analogous to ML-KEM and ML-DSA, 
> or should those remain unmapped for now?
>
> Best
> Stavros
>
>
> On 9/23/26 11:14 AM, Werner Koch wrote:
>> Hello!
>>
>> thanks for working with GPGME and for your patch.
>>
>> I see two problems with your implementation:
>>
>> 1. The name of the identifiers do not match those used by GnuPG.  For
>>     example GPGME_PK_MLKEM768_X25519 vs PUBKEY_ALGO_MLK768_25519 in
>>     GnuPG.  This is of course easy to fix by using 
>> GPGME_PK_MLK768_25519.
>>
>>     Also for "ML-KEM-768+X25519" vs. "mlk768".  For the new Brainpool
>>     support we use "mlk768_bp384".
>>
>> 2. A combinatorial explosion due to the way RFC-9850 work.  In gpgme we
>>     should avoid this.  For example there is an internal mapping
>>
>>       int
>>       _gpgme_map_pk_algo (int algo, gpgme_protocol_t protocol)
>>       {
>>         if (protocol == GPGME_PROTOCOL_OPENPGP)
>>           {
>>             switch (algo)
>>               {
>>               case 1: case 2: case 3: case 8: case 16: case 17: break;
>>               case 18: algo = GPGME_PK_ECDH; break;
>>               case 19: algo = GPGME_PK_ECDSA; break;
>>               case 20: break;
>>               case 22: algo = GPGME_PK_EDDSA; break;
>>               default: algo = 0; break; /* Unknown.  */
>>               }
>>           }
>>
>>     used to map the OpenPGP algorithm numbers to to those used by
>>     Libgcrypt.  This is actually straighforward but in Libgcrypt we do
>>     not have separate Ids for each ML-KEM/ECDH combination. Instead we
>>     use one identifier (8 for ML-KEM with ECDH) and use the length and
>>     curve parameter to specify the details.  This reflects what we have
>>     always done with RSA, Elgamal, and ECC: A base algorithm and
>>     parameters for the details.
>>
>>     For the 9980 algos I would suggest to map all ML-KEM algos to a new
>>     GPGME_PK_MLKEM which will match a new GCRY_PK_MLKEM Peseudo ID with
>>     value 331.  For the ML-DSA algos a GPGME_PK_MLDSA would match the
>>     Libgcrypt GCRY_PK_MLDSA identifier (value 332).  Using these new
>>     identifiers we can keep the IETF way of combining the algos apart
>>     from your and the BSIs original key combiner (as specified by
>>     LibrePGP).  They are already denoted by GPGME_PK_KYBER and
>>     (eventually) GPGME_PK_DILITHIUM.
>>
>>     GPGME applications already need to take the curve (and length)
>>     parameter in account and thus can decide whether the 9980 or the
>>     LibrePGP key combiner is used.
>>
>>
>> BTW, GnuPG 2.5.23 was released yesterday with support for 9980 inclduing
>> Brainpool and NIST versions of ML-KEM.
>>
>>
>>
>> Salam-Shalom,
>>
>>     Werner
>>
>>
-- 
TH Köln E-Mail-Signatur – Prof. Dr. Stavros Kousidis
*Prof. Dr. Stavros Kousidis*
Faculty of Information, Media and Electrical Engineering
Institute of Computer and Communication Technology
www.th-koeln.de/en/person/stavros.kousidis/ 
<https://www.th-koeln.de/en/person/stavros.kousidis/>
TH Köln - University of Applied Sciences
Campus Deutz
Betzdorfer Straße 2, 50679 Köln
TH Köln – Technology Arts Sciences

From wk at gnupg.org  Wed Sep 23 16:40:04 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 23 Sep 2026 16:40:04 +0200
Subject: GnuPG 2.5.23 no longer recognizes Token2 USB key
In-Reply-To: <uzex86wlj@gentoo.org> ("Ulrich =?utf-8?Q?M=C3=BCller?= via
 Gnupg-devel"'s message
	of "Wed, 23 Sep 2026 13:22:32 +0200")
References: <uzex86wlj@gentoo.org>
Message-ID: <87a4p8owu3.fsf@jacob.g10code.de>

On Wed, 23 Sep 2026 13:22, Ulrich Müller said:

> After downgrading to gnupg-2.5.22 it works again.

You should have waited for the announcement ;-).  There won't be one for
2.5.23 but one for .24 which I upload a few hours ago.


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/20260923/0a0bac31/attachment.sig>

From wk at gnupg.org  Wed Sep 23 16:38:18 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 23 Sep 2026 16:38:18 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de> (Stavros
	Kousidis via Gnupg-devel's message of "Wed, 23 Sep 2026 11:46:21
	+0200")
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
	<87se30pbxj.fsf@jacob.g10code.de>
	<7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
Message-ID: <87ecekowx1.fsf@jacob.g10code.de>

On Wed, 23 Sep 2026 11:46, Stavros Kousidis said:
> I’ll also align the GnuPG-facing names with the existing GnuPG naming
> conventions.

Thanks.

> One question before I send v2: how would you like the RFC 9980 SLH-DSA
> algorithm IDs 32–34 represented? Should there be a generic
> |GPGME_PK_SLHDSA| pseudo identifier, analogous to ML-KEM and ML-DSA,
> or should those remain unmapped for now?

Given that we have even no support for ML-DSA yet I see no need to hurry
adding additional algorithms like SLH-DSA now.  Adding ML_DSA is okay
because we have a concrete plan to implement 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/20260923/6fdebb26/attachment.sig>

From ulm at gentoo.org  Wed Sep 23 19:49:50 2026
From: ulm at gentoo.org (=?utf-8?Q?Ulrich_M=C3=BCller?=)
Date: Wed, 23 Sep 2026 19:49:50 +0200
Subject: GnuPG 2.5.23 no longer recognizes Token2 USB key
In-Reply-To: <87a4p8owu3.fsf@jacob.g10code.de>
References: <uzex86wlj@gentoo.org> <87a4p8owu3.fsf@jacob.g10code.de>
Message-ID: <uv77v7t8h@gentoo.org>

>>>>> On Wed, 23 Sep 2026, Werner Koch wrote:

> You should have waited for the announcement ;-).  There won't be one
> for 2.5.23 but one for .24 which I upload a few hours ago.

Thanks. 2.5.24 fixes the problem for me.

From andrewg at andrewg.com  Thu Sep 24 00:53:50 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 23 Sep 2026 23:53:50 +0100
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <87ecekowx1.fsf@jacob.g10code.de>
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
 <87se30pbxj.fsf@jacob.g10code.de>
 <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
 <87ecekowx1.fsf@jacob.g10code.de>
Message-ID: <4f74e02f-00dd-41cf-8840-67c41f800162@andrewg.com>

Hi, Werner.

On 23/09/2026 15:38, Werner Koch via Gnupg-devel wrote:
> Given that we have even no support for ML-DSA yet I see no need to hurry
> adding additional algorithms like SLH-DSA now.  Adding ML_DSA is okay
> because we have a concrete plan to implement this.

That's great news, thanks for the heads up! I agree there's no rush for 
SLH-DSA for the vast majority of users. I'm curious though, will ML-DSA 
support be RFC-9980 compatible in all compliance modes, or do you plan 
to implement a separate LibrePGP flavour, as per ML-KEM?

Thanks,
A


From wk at gnupg.org  Thu Sep 24 11:24:49 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 24 Sep 2026 11:24:49 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <4f74e02f-00dd-41cf-8840-67c41f800162@andrewg.com> (Andrew
	Gallagher via Gnupg-devel's message of "Wed, 23 Sep 2026 23:53:50
	+0100")
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
	<87se30pbxj.fsf@jacob.g10code.de>
	<7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
	<87ecekowx1.fsf@jacob.g10code.de>
	<4f74e02f-00dd-41cf-8840-67c41f800162@andrewg.com>
Message-ID: <87ik3vngri.fsf@jacob.g10code.de>

On Wed, 23 Sep 2026 23:53, Andrew Gallagher said:
> for SLH-DSA for the vast majority of users. I'm curious though, will
> ML-DSA support be RFC-9980 compatible in all compliance modes, or do
> you plan to implement a separate LibrePGP flavour, as per ML-KEM?

Unfortunately we are forced to implement both variants.  One for the PGP
crowd and one for the NSA/IETF crowd.


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/20260924/d9077110/attachment.sig>

From wk at gnupg.org  Thu Sep 24 11:35:25 2026
From: wk at gnupg.org (Werner Koch)
Date: Thu, 24 Sep 2026 11:35:25 +0200
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <d43aaa28-bbd7-45bf-ba68-979272b66b05@th-koeln.de> (Stavros
	Kousidis via Gnupg-devel's message of "Wed, 23 Sep 2026 15:24:47
	+0200")
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
	<87se30pbxj.fsf@jacob.g10code.de>
	<7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
	<d43aaa28-bbd7-45bf-ba68-979272b66b05@th-koeln.de>
Message-ID: <87ecejng9u.fsf@jacob.g10code.de>

On Wed, 23 Sep 2026 15:24, Stavros Kousidis said:

> For the latter, the algorithm identifier denotes a family and
> parameters such as curve or key size complete the definition. For the
> RFC 9980 composites, the OpenPGP algorithm identifier itself already
> denotes the complete construction, e.g. ML-KEM-768+X25519.

Which is a major problem with that IETF reworked BSI draft.  It drives
OpenPGP into the same complexity as we have seen for TLS with its
hundreds of algorithm combinations.

> Mapping that back to |GPGME_PK_MLKEM| plus auxiliary parameters
> therefore decomposes a protocol-defined algorithm and requires
> applications to reconstruct its identity afterwards. I think that is

We already do some of this.  GPGME is an abstraction layer and thus
should hide some of the complexity.  The algorithm numbers are anyway
only used for information/diagnostics.

> two cryptographic components, and |768| is a parameter-set
> designation, not a key length or security strength in bits.

This is the same as with DSA where a the specified length is also
implictly includes the subgroup size.

> mismatches. I strongly think this should not be pursued, and that the
> protocol-defined composite algorithm should remain represented as such
> rather than being decomposed and reconstructed later.

When generating the key you need to provide an algorithm string, like

 "ed25519/cert,sign+cv25519/encr" or its current alias "default"

 "bp384/cert,sign+kyber768_bp256/encr" or its current alias "pqc"
 
 "ietf27/cert,sign+mlk768_bp384/encr" or its current alias "pqc9980"

and no algorithm numbers. 


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/20260924/8fe19d30/attachment.sig>

From andrewg at andrewg.com  Thu Sep 24 15:22:23 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 24 Sep 2026 14:22:23 +0100
Subject: [PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms
In-Reply-To: <87ik3vngri.fsf@jacob.g10code.de>
References: <7acd9e26-e86c-475d-91d9-4e7af7f5bdad@th-koeln.de>
 <87se30pbxj.fsf@jacob.g10code.de>
 <7bcfcf7a-9e08-43ea-ad0b-f22ed8048029@th-koeln.de>
 <87ecekowx1.fsf@jacob.g10code.de>
 <4f74e02f-00dd-41cf-8840-67c41f800162@andrewg.com>
 <87ik3vngri.fsf@jacob.g10code.de>
Message-ID: <d2cdd446-7a22-4879-9c2b-514ec69b07f6@andrewg.com>

Hi, Werner.

On 24/09/2026 10:24, Werner Koch wrote:
> On Wed, 23 Sep 2026 23:53, Andrew Gallagher said:
>> for SLH-DSA for the vast majority of users. I'm curious though, will
>> ML-DSA support be RFC-9980 compatible in all compliance modes, or do
>> you plan to implement a separate LibrePGP flavour, as per ML-KEM?
> 
> Unfortunately we are forced to implement both variants.  One for the PGP
> crowd and one for the NSA/IETF crowd.
I'm sorry to hear this. I understand that you are effectively forced to 
implement RFC9980, and that you would much prefer to implement PQC 
signatures similarly to the LibrePGP Kyber architecture. It's not clear 
to me though what *forces* you to maintain parallel variants for 
features that have not yet been developed, let alone shipped. Won't this 
just mean extra work for everyone?

A