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.
--