From jcb62281 at gmail.com  Thu May  1 04:08:59 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 30 Apr 2025 21:08:59 -0500
Subject: [PATCH gnupg] Fix gcc -Wunterminated-string-initialization
 warnings.
In-Reply-To: <20250430040211.782774-1-collin.funk1@gmail.com>
References: <20250430040211.782774-1-collin.funk1@gmail.com>
Message-ID: <f076a8a7-e1f5-4011-98ec-6fca5c436f7a@gmail.com>

On 4/29/25 23:01, Collin Funk via Gnupg-devel wrote:
> * common/ksba-io-support.c (ATTR_NONSTRING): New macro.
> (bintoasc): Mark with ATTR_NONSTRING.
> (has_only_base64): Use memchr since calling strchr on a non-NUL
> terminated string is undefined behavior.
> * dirmngr/dns.c (DNS_NONSTRING): New macro.
> (dns_aaaa_arpa, dns_sshfp_print): Mark a variable with DNS_NONSTRING.

The patch as written breaks compatibility with GCC < GCC8 and with other 
compilers because it neglects to define the new macros with empty 
expansions on older or non-GCC compilers.

> [...]
> diff --git a/common/ksba-io-support.c b/common/ksba-io-support.c
> index 352485ffa..10419ab20 100644
> --- a/common/ksba-io-support.c
> +++ b/common/ksba-io-support.c
> @@ -51,6 +51,9 @@
>     #define LF "\n"
>   #endif
>   
> +#if __GNUC__ >= 8
> +# define ATTR_NONSTRING __attribute__ ((__nonstring__))
> +#endif
>   
>   /* Data used by the reader callbacks.  */
>   struct reader_cb_parm_s
> [...]
> diff --git a/dirmngr/dns.c b/dirmngr/dns.c
> index 5c7bb08d8..bfab59f13 100644
> --- a/dirmngr/dns.c
> +++ b/dirmngr/dns.c
> @@ -131,6 +131,9 @@ typedef int socket_fd_t;
>   #if __GNUC__
>   #define DNS_NOTUSED __attribute__((unused))
>   #define DNS_NORETURN __attribute__((__noreturn__))
> +#if __GNUC__ >= 8
> +#define DNS_NONSTRING __attribute__((__nonstring__))
> +#endif
>   #else
>   #define DNS_NOTUSED
>   #define DNS_NORETURN
> [...]


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250430/0f7d15b1/attachment-0001.html>

From collin.funk1 at gmail.com  Thu May  1 05:06:12 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Wed, 30 Apr 2025 20:06:12 -0700
Subject: [PATCH gnupg] Fix gcc -Wunterminated-string-initialization
 warnings.
In-Reply-To: <f076a8a7-e1f5-4011-98ec-6fca5c436f7a@gmail.com>
References: <20250430040211.782774-1-collin.funk1@gmail.com>
 <f076a8a7-e1f5-4011-98ec-6fca5c436f7a@gmail.com>
Message-ID: <874iy59gij.fsf@gmail.com>

Jacob Bachmeyer <jcb62281 at gmail.com> writes:

> The patch as written breaks compatibility with GCC < GCC8 and with
> other compilers because it neglects to define the new macros with
> empty expansions on older or non-GCC compilers.

Oops, silly oversight on my part.

I think it is fine to just wait for GPGRT_ATTR_NONSTRING anyways. So no
big deal that this patch is incorrect.

Thanks,
Collin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250430/9f085238/attachment.sig>

From collin.funk1 at gmail.com  Thu May  1 06:35:30 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Wed, 30 Apr 2025 21:35:30 -0700
Subject: [PATCH libassuan] Work around missing getpeereid declaration on AIX.
Message-ID: <20250501043542.479678-1-collin.funk1@gmail.com>

* configure.ac: Check for a declaration of getpeereid.
* src/assuan-socket-server.c (getpeereid)
[HAVE_GETPEEREID && !HAVE_DECL_GETPEEREID]: Declare function.
(accept_connection_bottom): Adjust a comment.

--
GnuPG-bug-id: 7631
Signed-off-by: Collin Funk <collin.funk1 at gmail.com>
---
 configure.ac               | 8 +++++++-
 src/assuan-socket-server.c | 7 ++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 979a7e4..bc4ff39 100644
--- a/configure.ac
+++ b/configure.ac
@@ -471,8 +471,14 @@ AC_CHECK_MEMBER(struct sockpeercred.pid,
 # (Open)Solaris
 AC_CHECK_FUNCS([getpeerucred])
 
-# FreeBSD
+# FreeBSD and AIX
 AC_CHECK_FUNCS([getpeereid])
+# AIX is missing the declaration.
+AC_CHECK_DECLS([getpeereid],,, [[
+#include <sys/types.h>
+#include <unistd.h>
+#include <sys/socket.h>
+]])
 AC_CHECK_MEMBER(struct xucred.cr_pid,
 		[AC_DEFINE(HAVE_XUCRED_CR_PID, 1,
 		 Define if struct xucred contains the cr_pid member.)],
diff --git a/src/assuan-socket-server.c b/src/assuan-socket-server.c
index c270e8d..8c44755 100644
--- a/src/assuan-socket-server.c
+++ b/src/assuan-socket-server.c
@@ -55,6 +55,11 @@
 #include "debug.h"
 #include "assuan-defs.h"
 
+/* Missing declaration on AIX.  */
+#if HAVE_GETPEEREID && !HAVE_DECL_GETPEEREID
+int getpeereid (int fd, uid_t *euid, gid_t *egid);
+#endif
+
 static gpg_error_t
 accept_connection_bottom (assuan_context_t ctx)
 {
@@ -130,7 +135,7 @@ accept_connection_bottom (assuan_context_t ctx)
       }
   }
 #elif defined(HAVE_GETPEEREID)
-  {                             /* FreeBSD */
+  {                             /* FreeBSD and AIX */
     if (getpeereid (fd, &ctx->peercred.uid, &ctx->peercred.gid) != -1)
       {
         ctx->peercred_valid = 1;
-- 
2.49.0



From collin.funk1 at gmail.com  Thu May  1 08:23:58 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Wed, 30 Apr 2025 23:23:58 -0700
Subject: [PATCH gnupg] tests:gpgscm: Fix build error on AIX.
Message-ID: <20250501062411.800702-1-collin.funk1@gmail.com>

* tests/gpgscm/ffi.c (ffi_init): Undefine 'open' so it does not get
expanded to 'open64' in the ffi_define_function macro.

--
GnuPG-bug-id: 7632
Signed-off-by: Collin Funk <collin.funk1 at gmail.com>
---
 tests/gpgscm/ffi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tests/gpgscm/ffi.c b/tests/gpgscm/ffi.c
index 21ec6a057..cdb794ad0 100644
--- a/tests/gpgscm/ffi.c
+++ b/tests/gpgscm/ffi.c
@@ -1667,6 +1667,11 @@ ffi_init (scheme *sc, const char *argv0, const char *scriptname,
   ffi_define_function (sc, getenv);
   ffi_define_function (sc, setenv);
   ffi_define_function_name (sc, "_exit", exit);
+  /* AIX defines open to open64 which breaks the macro expansion to
+     'do_open' if it is not undefined.  */
+#ifdef open
+# undef open
+#endif
   ffi_define_function (sc, open);
   ffi_define_function (sc, fdopen);
   ffi_define_function (sc, close);
-- 
2.49.0



From pschwabauer at intevation.de  Fri May  2 11:26:26 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Fri, 2 May 2025 11:26:26 +0200
Subject: gpgmepy: Broken sdist build => "make install fails"
In-Reply-To: <19f72dbaa8a2d57abdecab7be40c09dc9383a7ed.camel@sapience.com>
References: <d2537a3a-2ebb-4a44-9ce8-24b80f679fb5@intevation.de>
 <8b7dd882-fb96-47cc-aa03-bc2d075f0af5@intevation.de>
 <19f72dbaa8a2d57abdecab7be40c09dc9383a7ed.camel@sapience.com>
Message-ID: <6dac033f-470b-4a2c-bd8a-386681438592@intevation.de>

With the latest commit, it's now possible to build a wheel package using 
|make && python -m build|, and install it with |pip install dist/*.whl|.
Note that the Makefile still invokes |setup.py| in several places, which 
is deprecated and already causes failures for |make install| and |make 
sdist|.
I now have write access to the repository and have fixed some of the 
build issues, but contributions are very welcome; especially since I'm 
not deeply familiar with the Python ecosystem.

On 4/30/25 18:34, Genes Lists wrote:
> On Wed, 2025-04-30 at 16:45 +0200, Paul Schwabauer via Gnupg-devel
> wrote:
> On a slightly related note, make install is now failing as below.
> Primary error seems to be :
>   
>     "NotImplementedError: Support for egg-based install has been
> removed"
>
> python 3.13.3
> setuptools 80.0.0
> on archlinux :
>
> thanks
>
> gene
> -----------
> Errors are:
>
> /usr/lib/python3.13/site-packages/setuptools/_distutils/cmd.py:90:
> SetuptoolsDeprecationWarning: setup.py install is deprecated.
>
> Traceback (most recent call last):
>    File "/mnt/lv_data/shared/src/abs/upstream/gnupg/gpgmepy-
> git/src/gpgmepy/build/setup.py", line 237, in <module>
>      setup(
>      ~~~~~^
>          cmdclass={'build': BuildExtFirstHack},
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      ...<5 lines>...
>          ],
>          ^^
>      )
>      ^
>    File "/usr/lib/python3.13/site-packages/setuptools/__init__.py", line
> 117, in setup
>      return distutils.core.setup(**attrs)
>             ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
>    File "/usr/lib/python3.13/site-
> packages/setuptools/_distutils/core.py", line 186, in setup
>      return run_commands(dist)
>    File "/usr/lib/python3.13/site-
> packages/setuptools/_distutils/core.py", line 202, in run_commands
>      dist.run_commands()
>      ~~~~~~~~~~~~~~~~~^^
>    File "/usr/lib/python3.13/site-
> packages/setuptools/_distutils/dist.py", line 1002, in run_commands
>      self.run_command(cmd)
>      ~~~~~~~~~~~~~~~~^^^^^
>    File "/usr/lib/python3.13/site-packages/setuptools/dist.py", line
> 1104, in run_command
>      super().run_command(command)
>      ~~~~~~~~~~~~~~~~~~~^^^^^^^^^
>    File "/usr/lib/python3.13/site-
> packages/setuptools/_distutils/dist.py", line 1021, in run_command
>      cmd_obj.run()
>      ~~~~~~~~~~~^^
>    File "/usr/lib/python3.13/site-
> packages/setuptools/command/install.py", line 105, in run
>      self.do_egg_install()
>      ~~~~~~~~~~~~~~~~~~~^^
>    File "/usr/lib/python3.13/site-
> packages/setuptools/command/install.py", line 143, in do_egg_install
>      raise NotImplementedError("Support for egg-based install has been
> removed.")
> NotImplementedError: Support for egg-based install has been removed.
> make[2]: *** [Makefile:986: install-exec-local] Error 1


From lists at sapience.com  Fri May  2 13:00:04 2025
From: lists at sapience.com (Genes Lists)
Date: Fri, 02 May 2025 07:00:04 -0400
Subject: gpgmepy: Broken sdist build => "make install fails"
In-Reply-To: <6dac033f-470b-4a2c-bd8a-386681438592@intevation.de>
References: <d2537a3a-2ebb-4a44-9ce8-24b80f679fb5@intevation.de>
 <8b7dd882-fb96-47cc-aa03-bc2d075f0af5@intevation.de>
 <19f72dbaa8a2d57abdecab7be40c09dc9383a7ed.camel@sapience.com>
 <6dac033f-470b-4a2c-bd8a-386681438592@intevation.de>
Message-ID: <40947f7069716a1e9e227efb33a28cd901bb85e2.camel@sapience.com>

On Fri, 2025-05-02 at 11:26 +0200, Paul Schwabauer wrote:
> With the latest commit, it's now possible to build a wheel package
> using 
> > make && python -m build|, and install it with |pip install
> > dist/*.whl|.

Thanks Paul - is there something I should do differently as it seems
not to build for me.

On fully updated archlinux with following versions installed:

? python 3.13.3-1
? swig 4.3.0-1
? python-setuptools 1:80.0.0-1
  python-build 1.2.2-3
  python-installer 0.7.0-10

With latest git head:

? git fetch --all
  git pull
  git clean -fdx
? ./autogen.sh --force

? mkdir ./build
? cd ./build

? ../configure --enable-maintainer-mode --prefix=/usr --disable-gpg-
test

? make

? /usr/bin/python -m build --wheel -v --no-isolation

Leads to (bunch of SPDX missing warnings then):

...

  self._finalize_license_expression()
running egg_info
writing gpg.egg-info/PKG-INFO
writing dependency_links to gpg.egg-info/dependency_links.txt
writing top-level names to gpg.egg-info/top_level.txt
reading manifest file 'gpg.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.org' under directory 'doc'
warning: no files found matching '*.tex' under directory 'doc'
warning: no files found matching '*.info' under directory 'doc'
warning: no files found matching '*.py' under directory 'examples'
warning: no files found matching '*.pyx' under directory 'examples'
warning: no files found matching 'README.org'
writing manifest file 'gpg.egg-info/SOURCES.txt'

ERROR Missing dependencies:
	swig

-- 
Gene
-------------- 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/20250502/d27ce6a5/attachment.sig>

From pschwabauer at intevation.de  Fri May  2 13:59:12 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Fri, 2 May 2025 13:59:12 +0200
Subject: Build requirements
Message-ID: <bd7a146e-c006-445f-b438-29cfb992829c@intevation.de>

If you build without isolation you need to install the swig package: 
|pip install swig|. The isolated environment automatically installs this 
package.



From lists at sapience.com  Fri May  2 16:45:59 2025
From: lists at sapience.com (Genes Lists)
Date: Fri, 02 May 2025 10:45:59 -0400
Subject: Build requirements
In-Reply-To: <bd7a146e-c006-445f-b438-29cfb992829c@intevation.de>
References: <bd7a146e-c006-445f-b438-29cfb992829c@intevation.de>
Message-ID: <b486c8494f647d821212ddd1f24d1c91cd18b81b.camel@sapience.com>

On Fri, 2025-05-02 at 13:59 +0200, Paul Schwabauer wrote:
> If you build without isolation you need to install the swig package: 
> > pip install swig|. The isolated environment automatically installs
> > this 
> package.
> 

hi Paul

That's what strange - swig is already installed in system area :

$ pacman -Q swig
swig 4.3.0-1

and yet the error as below:

Can it be related to the 'egg' stuff being deprecated in setuptools
80.0.0?
Or maybe whatever 'swig' test is done is not working for some reason
here?

----------------------------------- log ---------
/usr/bin/python -m build --wheel --no-isolation

self._finalize_license_expression()

running egg_info
creating src/gpg.egg-info
writing src/gpg.egg-info/PKG-INFO
writing dependency_links to src/gpg.egg-info/dependency_links.txt
writing top-level names to src/gpg.egg-info/top_level.txt
writing manifest file 'src/gpg.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching '*.rst' under directory 'doc'
warning: no files found matching '*.texi' under directory 'doc'
warning: no files found matching '*.info' under directory 'doc'
warning: no files found matching 'version.py'
warning: no files found matching '*.py' under directory 'gpg'
adding license file 'COPYING'
adding license file 'COPYING.LESSER'
adding license file 'AUTHORS'

writing manifest file 'src/gpg.egg-info/SOURCES.txt'

ERROR Missing dependencies:
swig


-- 
Gene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250502/9c36aea6/attachment.html>
-------------- 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/20250502/9c36aea6/attachment.sig>

From lists at sapience.com  Sun May  4 20:17:08 2025
From: lists at sapience.com (Genes Lists)
Date: Sun, 04 May 2025 14:17:08 -0400
Subject: Build requirements (was gpgmepy broken build)
In-Reply-To: <b486c8494f647d821212ddd1f24d1c91cd18b81b.camel@sapience.com>
References: <bd7a146e-c006-445f-b438-29cfb992829c@intevation.de>
 <b486c8494f647d821212ddd1f24d1c91cd18b81b.camel@sapience.com>
Message-ID: <c0036a1ab3dacb453efcbcafa768d76f7554aa83.camel@sapience.com>

Am starting to feel like gpgmepy is kind of abandonware? Maybe its time
to move on.

I note that pysequoia is readily available, has up to date python
tooling, wraps the sq rust library and is actively maintained.
So it might be good alternative for some folks.



-- 
Gene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250504/8ff6f1a1/attachment.html>
-------------- 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/20250504/8ff6f1a1/attachment.sig>

From collin.funk1 at gmail.com  Sun May  4 20:46:52 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sun,  4 May 2025 11:46:52 -0700
Subject: [PATCH gnupg] common: Add Solaris support to get_signal_name.
Message-ID: <20250504184707.191051-1-collin.funk1@gmail.com>

* configure.ac: Check for _sys_siglist.
* common/signal.c (get_signal_name): Use _sys_siglist.

--

GnuPG-bug-id: 7638
Signed-off-by: Collin Funk <collin.funk1 at gmail.com>
---
 common/signal.c | 8 ++++++--
 configure.ac    | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/common/signal.c b/common/signal.c
index d308c175c..a56e6d6f4 100644
--- a/common/signal.c
+++ b/common/signal.c
@@ -89,8 +89,12 @@ get_signal_name( int signum )
      reentrant. */
 #if HAVE_SIGDESCR_NP
   return sigdescr_np (signum);
-#elif HAVE_DECL_SYS_SIGLIST && defined(NSIG)
-  return (signum >= 0 && signum < NSIG) ? sys_siglist[signum] : "?";
+#elif (HAVE_DECL_SYS_SIGLIST || HAVE_DECL__SYS_SIGLIST) && defined(NSIG)
+#if HAVE_DECL_SYS_SIGLIST
+#undef _sys_siglist
+#define _sys_siglist sys_siglist
+#endif
+  return (signum >= 0 && signum < NSIG) ? _sys_siglist[signum] : "?";
 #else
   return NULL;
 #endif
diff --git a/configure.ac b/configure.ac
index 1c1c892ca..29aa30973 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1341,7 +1341,7 @@ fi
 AC_TYPE_SIZE_T
 AC_TYPE_MODE_T
 AC_CHECK_FUNCS([sigdescr_np])
-AC_CHECK_DECLS([sys_siglist],[],[],[#include <signal.h>
+AC_CHECK_DECLS([sys_siglist, _sys_siglist],[],[],[#include <signal.h>
 /* NetBSD declares sys_siglist in unistd.h.  */
 #ifdef HAVE_UNISTD_H
 # include <unistd.h>
-- 
2.49.0



From kloecker at kde.org  Mon May  5 16:44:16 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Mon, 05 May 2025 16:44:16 +0200
Subject: Build requirements (was gpgmepy broken build)
In-Reply-To: <c0036a1ab3dacb453efcbcafa768d76f7554aa83.camel@sapience.com>
References: <bd7a146e-c006-445f-b438-29cfb992829c@intevation.de>
 <b486c8494f647d821212ddd1f24d1c91cd18b81b.camel@sapience.com>
 <c0036a1ab3dacb453efcbcafa768d76f7554aa83.camel@sapience.com>
Message-ID: <2745879.vuYhMxLoTh@daneel>

On Sonntag, 4. Mai 2025 20:17:08 Mitteleurop?ische Sommerzeit Genes Lists 
wrote:
> Am starting to feel like gpgmepy is kind of abandonware? Maybe its time
> to move on.

The Python bindings have been neglected for some time (except for minor 
maintenance). Paul has just started to change this.

Regards,
Ingo
-------------- 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/20250505/04eb0166/attachment.sig>

From lucas.mulling at suse.com  Tue May  6 19:19:01 2025
From: lucas.mulling at suse.com (Lucas Mulling)
Date: Tue, 06 May 2025 14:19:01 -0300
Subject: Setting max-cache-ttl to 0 does not disable caching
Message-ID: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>

Hello,

A few users have questioned a change in behaviour from version 2.4.7 to
2.5.0 (commit 92de0387f04b1e87a4a49ed063323624f25ac3ef) where setting
max-cache-ttl to 0 does not disable password caching anymore, is this
change intended?

See discussion here: https://bugzilla.suse.com/show_bug.cgi?id=1241656

Thank you,
Lucas M?lling


From dkg at fifthhorseman.net  Tue May  6 22:24:41 2025
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 May 2025 16:24:41 -0400
Subject: GnuPG Web-of-Trust calculations based on trust-signatures don't add
 up (T7611)
Message-ID: <875xidh4hi.fsf@fifthhorseman.net>

Hey folks--

I just wanted to give people a heads-up that GnuPG's web-of-trust
calculations are ? surprising to me, to say the least.  In particular,
*adding* a trust signature to a WoT path can apparently *reduce* the
calculated validity of a target userID+certificate.

If anyone is actually relying on Web-of-Trust calculations from GnuPG
for their project, i hope you'll take a look at this issue and weigh in
on whether it meets your expectations or not.

Over on https://dev.gnupg.org/T7611 there is a simple script that
generates an example graph that looks like this:

```
      ?2    ?1
Alice ?? Bob ?? Carol ? Dave [marginal]
  ?2 ?        ??1
         Bill
```

Legend: ?x means "trust signature (tsig) with full trust of depth x" and
?y means "tsig with marginal trust of depth y".

With the full graph of tsigs shown here, and with Alice being ultimately
trusted, GnuPG claims that Dave's certificate has marginal validity.

If we remove the tsig from Alice to Bill, then Dave's certificate
increases from marginal to full validity.

```
      ?2    ?1
Alice ?? Bob ?? Carol ? Dave [full]
              ??1
         Bill
```

That's right: *removing* an independent tsig causes calculated validty
to *increase*.  And vice versa: *adding* an independent tsig causes
calculated validty to *decrease*.

In that ticket, Werner identified this as desired/intended behavior, and
asked for further conversation to happen on this mailing list, hence
this e-mail message.

To be clear about my understanding:

 - I generally expect WoT calculations to be cumulative or additive in
   some sense.  For example, gpg(1) documents the --marginals-needed
   option as "Number of marginally trusted users to introduce a new key
   signer".  This implies (to me, anyway) that adding a marginally
   trusted certification should be able to *increase* the validity of a
   user ID in an OpenPGP certificate.

 - I find it surprising that the addition of a marginally trusted user
   (without superseding any existing certification) would actually
   *reduce* the amount of confidence in the validity of some
   certificate.

 - The code archaeology in T7611 turns up a (rather old) comment
   suggesting that timestamps of signature creation should make some
   sort of difference.  But in the tests i ran, all signatures and all
   certificates are made within the same second, the finest temporal
   resolution that OpenPGP is capable of recording.  So i'm not sure how
   questions about timestamp are relevant.

I want to also note that it's possible that no one is relying on
Web-of-Trust calculations from GnuPG.  From my perspective:

 - I contributed for years to the Monkeysphere (which validated SSH
   cryptographic keys for SSH servers and users), which basically
   assumed that GnuPG's WoT calculations could be relied on, but i don't
   think anyone in that project (including me) ever tested complex
   graphs.  As far as i know, Monkeysphere was ever only deployed with
   single-hop certification authorities in either direction.  For
   example, the ssh user would privately/internally certify the SSH
   host's OpenPGP certificate.  And the SSH host administrator might
   certify the end-user's OpenPGP certificate, which the SSH host itself
   would rely on.

 - For Debian's keyring-maint (where i act as an advisor), which does
   ask questions about OpenPGP certification connectivity, it really
   only uses single-hop certifications from any of a known set of Debian
   Developer certificates.  Interesting graphs can be drawn about WoT
   connectivity from those structures, but they have no concrete effect
   on how Debian works, and they typically aren't using GnuPG's userid
   validity or trust calculations anyway.

 - For regular e-mail address cryptographic identity management, I've
   only ever seen people using the OpenPGP tooling for management of a
   TOFUish keystore, even when they use GnuPG.  Alternately, people
   using OpenPGP might use an entirely non-WoT scheme like the Autocrypt
   recommendation engine.

It would be pretty cool if the OpenPGP WoT was useful in some contexts,
but none of the above seem to actually use it.  And if there is a system
that uses it where GnuPG is in the mix, I'd live to hear about it!  In
such a case, i hope the folks who depend on that system will not be
surprised by this report.  If you're one of those people, I'd be
particularly interested to learn more about your mental model of the
network of OpenPGP identity certifications that we know as the "web of
trust", so i can understand it better.

All the best,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250506/cc70f39c/attachment-0001.sig>

From simon at josefsson.org  Tue May  6 23:04:40 2025
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 May 2025 23:04:40 +0200
Subject: GnuPG Web-of-Trust calculations based on trust-signatures don't
 add up (T7611)
In-Reply-To: <875xidh4hi.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-devel's message of "Tue, 06 May 2025 16:24:41 -0400")
References: <875xidh4hi.fsf@fifthhorseman.net>
Message-ID: <87y0v9e9hz.fsf@josefsson.org>

Daniel Kahn Gillmor via Gnupg-devel <gnupg-devel at gnupg.org> writes:

>  - I generally expect WoT calculations to be cumulative or additive in
>    some sense.

I think that may be a fundamental problem.  I don't know PGP WoT but
here is a thought experiment:

If someone identify themselves using a governmental ID that I can
verify, I tend to assign some trust to that.

If they next identify themselves using ANOTHER governmental ID that
claim something else, I would still tend to assign this identification
some trust, but less than in the first situation.  That's because I now
have proof that some step in my identification is ambigious.

So I don't think identity trust calculations must generally always be
additive when given more information.

Before someone suggests that I shouldn't assign trust to this situation,
recall that this situation happens in the real world.  People show me a
passport and I'm happy to sign the fingerprint.  Then they show me a
driver's id that has another last name or similar and go "oh never mind
the different name, I got married".  I'm still happy to sign the
fingerprint, but I'm not as confident about what the identity really is.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250506/1375427f/attachment.sig>

From dkg at fifthhorseman.net  Wed May  7 01:36:28 2025
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 May 2025 19:36:28 -0400
Subject: GnuPG Web-of-Trust calculations based on trust-signatures don't
 add up (T7611)
In-Reply-To: <87y0v9e9hz.fsf@josefsson.org>
References: <875xidh4hi.fsf@fifthhorseman.net> <87y0v9e9hz.fsf@josefsson.org>
Message-ID: <87wmatfh1f.fsf@fifthhorseman.net>

On Tue 2025-05-06 23:04:40 +0200, Simon Josefsson wrote:
> Daniel Kahn Gillmor via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
>>  - I generally expect WoT calculations to be cumulative or additive in
>>    some sense.
>
> I think that may be a fundamental problem.

I should probably have said "potentially corroborative" or something.  I
didn't mean to imply that every additional certification *must* increase
calculated validity, only that i don't expect additional certifications
to *reduce* validity.

In your discussion below, i think you're using the term "trust" to mean
both "calculated validity" (how much do i believe this certificate
belongs to the claimed User ID?) and "assigned ownertrust" (how much am
i willing to rely on cryptographic identity certifications made by this
key?)

In your sharp observation i think you're talking about the "validity" of
two *different* names associated with a single underlying cryptograpic
identity.

> So I don't think identity trust calculations must generally always be
> additive when given more information.

Right, i can see how that is an interesting counter-point: two mutually
conflicting identity assertions about the same underlying principal
should make either identity assertion *less* confident than it was
before.

I don't know of any WoT implementation that includes this kind of
heuristic, but i can see why it might be desirable.

For the sake of the discussion here though, i was talking about how to
think about certifications that all *agree* on the uid+key binding
(validity), but maybe differ in degree of trust asserted.

I had worked from the following observations:

 - three certifications from "marginally trusted" certifiers add up to
   full calculated validity for the subject.

 - a certification from a "fully trusted" certifier *also* endows the
   subject with full calculated validity.

 - one certification from a "fully trusted" certifier plus another
   certification from a "marginally trusted" certifier *also* endows the
   subject with full calculated validity.  (i think -- i'm realizing now
   that i haven't explicitly tested this claim which i thought was
   non-controversial)

 - a "full" tsig at depth N results in the subject being a fully-trusted
   certifier with depth N-1.

From the above, i'd assumed that

 - the one "marginal" tsig at depth N plus one "full" tsig at identical
   depth N would result in a fully-trusted certifier with depth N-1.

But this last thing appears to not be the case.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250506/677b0baf/attachment.sig>

From simon at josefsson.org  Wed May  7 10:54:26 2025
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 May 2025 10:54:26 +0200
Subject: GnuPG Web-of-Trust calculations based on trust-signatures don't
 add up (T7611)
In-Reply-To: <87wmatfh1f.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-devel's message of "Tue, 06 May 2025 19:36:28 -0400")
References: <875xidh4hi.fsf@fifthhorseman.net> <87y0v9e9hz.fsf@josefsson.org>
 <87wmatfh1f.fsf@fifthhorseman.net>
Message-ID: <87r010er7h.fsf@josefsson.org>

Daniel Kahn Gillmor via Gnupg-devel <gnupg-devel at gnupg.org> writes:

>> So I don't think identity trust calculations must generally always be
>> additive when given more information.
>
> Right, i can see how that is an interesting counter-point: two mutually
> conflicting identity assertions about the same underlying principal
> should make either identity assertion *less* confident than it was
> before.

No, I didn't mean that the two IDs provide assertions that conflict, and
I see now that my example was unclear and gave that impression.  While
it may appear that way, I don't believe one passport for a person with
name X and a drivers license for the same person with name Y is
necessarily asserting anything that conflicts.  A person can have
multiple names at different points in time, and it is common for people
to have multiple valid names at the same point in time too.  When
mapping this to a digital world, I think it is reasonable to give full
confidence to a simple chain of assertion claims, but less confidence to
a more complex chain.  Which seems somewhat similar to the example you
gave.  And more in line with common human trust confidence behaviour --
if you only have one person available for trust, you have no choice than
to trust 100% but if another person comes along you could trust 99%/1%
or 50%/50% depending on properties.  Mapping human trust calculations
into anything digital seems hard, though, and my head hurts when I try
to map any of this into PGP WoT principles.  But I'm not certain that
finding surprising examples is always a bug.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250507/e6fbb5a2/attachment.sig>

From sachin.t at ibm.com  Wed May  7 17:14:39 2025
From: sachin.t at ibm.com (Sachin T)
Date: Wed, 7 May 2025 15:14:39 +0000
Subject: Request to Create account for contribution
Message-ID: <CO1PR15MB5003EB444CFE8F31322A96119788A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hi GnuPG team,

I hope you?re doing well. I need to register an account to contribute patches related to IBM z/OS platform

As part of the zOpen community https://github.com/zopencommunity), where we work on porting open-source tools to z/OS.  As part of this effort, we have ported GnuPG and its related libraries to z/OS and made various improvements. We would now like to contribute back by upstreaming the patches we have developed.
For reference, here are the GitHub links to the patches we have done so far for the GnuPG project and its libraries:

  *   GnuPG: https://github.com/zopencommunity/gpgport/tree/main/patches
  *   Libgcrypt: https://github.com/zopencommunity/libgcryptport/tree/main/patches
  *   Libassuan: https://github.com/zopencommunity/libassuanport/tree/main/patches
  *   Libksba: https://github.com/zopencommunity/libksbaport/tree/main/patches
  *   NPTH: https://github.com/zopencommunity/npthport/tree/main/patches
  *   Ntbls: https://github.com/zopencommunity/ntbtlsport/tree/main/patches
  *   Libgpgerror: https://github.com/zopencommunity/libgpgerrorport/tree/main/patches
  *   Pinentry: https://github.com/zopencommunity/pinentryport/tree/main/patches

Please let me know if there are any updates on the account creation process or if you need any additional details from us. We appreciate your support and look forward to contributing to the GnuPG community.
Here are my preferred account details.

Preferred credential
Handle - sachint
shown name ? Sachin T
mail address ? Sachin.t at ibm.com<mailto:Sachin.t at ibm.com>

Regards
Sachin

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

From gniibe at fsij.org  Thu May  8 04:20:21 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 08 May 2025 11:20:21 +0900
Subject: Setting max-cache-ttl to 0 does not disable caching
In-Reply-To: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>
References: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>
Message-ID: <87tt5vdesa.fsf@haruna.fsij.org>

Hello,

Lucas Mulling wrote:
> A few users have questioned a change in behaviour from version 2.4.7 to
> 2.5.0 (commit 92de0387f04b1e87a4a49ed063323624f25ac3ef) where setting
> max-cache-ttl to 0 does not disable password caching anymore, is this
> change intended?

Sorry, it's not intended change.  I overlooked this use case of setting
max-cache-ttl to 0.

To disable caching, I think that you can do by:

	default-cache-ttl 0

Possible fix to recover the same semantics would be the following.

==========================
diff --git a/agent/cache.c b/agent/cache.c
index e8544205f..fbe1c1f14 100644
--- a/agent/cache.c
+++ b/agent/cache.c
@@ -318,6 +318,7 @@ compute_expiration (ITEM r)
   unsigned long maxttl;
   time_t current = gnupg_get_time ();
   time_t next;
+  int no_maxttl = 0;
 
   if (r->cache_mode == CACHE_MODE_PIN)
     return 0; /* Don't let it expire - scdaemon explicitly flushes them.  */
@@ -334,13 +335,16 @@ compute_expiration (ITEM r)
     {
     case CACHE_MODE_DATA:
     case CACHE_MODE_PIN:
-      maxttl = 0;  /* No MAX TTL here.  */
+      no_maxttl = 1;
+      /* No MAX TTL here.  */
       break;
     case CACHE_MODE_SSH: maxttl = opt.max_cache_ttl_ssh; break;
     default: maxttl = opt.max_cache_ttl; break;
     }
 
-  if (maxttl)
+  if (no_maxttl)
+    next = 0;
+  else
     {
       if (r->created + maxttl < current)
         {
@@ -351,8 +355,6 @@ compute_expiration (ITEM r)
 
       next = r->created + maxttl - current;
     }
-  else
-    next = 0;
 
   if (r->ttl >= 0 && (next == 0 || r->ttl < next))
     {
-- 


From wk at gnupg.org  Thu May  8 10:25:14 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 May 2025 10:25:14 +0200
Subject: [PATCH gnupg] tests:gpgscm: Fix build error on AIX.
In-Reply-To: <20250501062411.800702-1-collin.funk1@gmail.com> (Collin Funk via
 Gnupg-devel's message of "Wed, 30 Apr 2025 23:23:58 -0700")
References: <20250501062411.800702-1-collin.funk1@gmail.com>
Message-ID: <878qn733x1.fsf@jacob.g10code.de>

On Wed, 30 Apr 2025 23:23, Collin Funk said:
> * tests/gpgscm/ffi.c (ffi_init): Undefine 'open' so it does not get
> expanded to 'open64' in the ffi_define_function macro.

Applied.  Thanks.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250508/9a629625/attachment.sig>

From wk at gnupg.org  Thu May  8 10:25:29 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 May 2025 10:25:29 +0200
Subject: [PATCH gnupg] common: Add Solaris support to get_signal_name.
In-Reply-To: <20250504184707.191051-1-collin.funk1@gmail.com> (Collin Funk via
 Gnupg-devel's message of "Sun, 4 May 2025 11:46:52 -0700")
References: <20250504184707.191051-1-collin.funk1@gmail.com>
Message-ID: <874ixv33wm.fsf@jacob.g10code.de>

On Sun,  4 May 2025 11:46, Collin Funk said:
> * configure.ac: Check for _sys_siglist.
> * common/signal.c (get_signal_name): Use _sys_siglist.

Applied.  Thanks.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250508/5d6a1ed3/attachment.sig>

From wk at gnupg.org  Thu May  8 10:24:58 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 May 2025 10:24:58 +0200
Subject: [PATCH gnupg] po: Fix misspelled italian translation for
 'encrypted'
In-Reply-To: <5007543.31r3eYUQgx@localhost> (Mattia Narducci via Gnupg-devel's
 message of "Wed, 16 Apr 2025 23:13:02 +0200")
References: <5007543.31r3eYUQgx@localhost>
Message-ID: <87cycj33xh.fsf@jacob.g10code.de>

Hi!

Thanks for the pacth.  A DCO is not required for tranlations.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250508/8c7d53c2/attachment.sig>

From wk at gnupg.org  Thu May  8 10:44:37 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 08 May 2025 10:44:37 +0200
Subject: Request to Create account for contribution
In-Reply-To: <CO1PR15MB5003EB444CFE8F31322A96119788A@CO1PR15MB5003.namprd15.prod.outlook.com>
 (Sachin T. via Gnupg-devel's message of "Wed, 7 May 2025 15:14:39
 +0000")
References: <CO1PR15MB5003EB444CFE8F31322A96119788A@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <87zffn1oga.fsf@jacob.g10code.de>

Hi!

On Wed,  7 May 2025 15:14, Sachin T said:

> I hope you?re doing well. I need to register an account to contribute
> patches related to IBM z/OS platform

Done.

> As part of the zOpen community https://github.com/zopencommunity),
> where we work on porting open-source tools to z/OS.  As part of this

And I though we don't need that anymore due to the available of Linux on
thatatform.  In fact some very old code to handle EBCDIC has already
been removed and we meanwhile assume UTF-8 encoding for everything.

I had a quick look at some patches and I am missing any documentation
for the patches.   Random example:

     case GNUPG_MODULE_NAME_CONNECT_AGENT:
-      X(bindir, "tools", "gpg-connect-agent");
+#if __MVS__
+       X(bindir, "bin", "gpg-connect-agent");
+#else
+       X(bindir, "tools", "gpg-connect-agent");
+#endif
 
Why do you need to change this?  The second arg is the build directory
and only used for internal build and regression test purposes.

Patches like

-     (pipe:gpg `(--yes -ea --recipient ,usrname2))
+     (pipe:gpg `(--yes -ea --recipient ,usrname2 --trust-model always))

Are not useful because that can't be a platform issue.  A patch to
configure is a no-go becuase configure is a built file.

   AC_CHECK_HEADER(zlib.h,
-     AC_CHECK_LIB(z, deflateInit2_,
+     AC_CHECK_LIB(z, deflate,

Is also not good because it breaks on existing platforms.  You need to
test for deflate only after you checked that deflateInit2_ does not exists.

The patches seem to be under a BSD license.  We can't accept this.  The
whole thing seems to be under Apache 2.0 License - this is incompatible
to the GPL; sorry.


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: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250508/fab7fa42/attachment.sig>

From lucas.mulling at suse.com  Thu May  8 20:33:50 2025
From: lucas.mulling at suse.com (Lucas Mulling)
Date: Thu, 08 May 2025 15:33:50 -0300
Subject: Setting max-cache-ttl to 0 does not disable caching
In-Reply-To: <87tt5vdesa.fsf@haruna.fsij.org>
References: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>
 <87tt5vdesa.fsf@haruna.fsij.org>
Message-ID: <D9QZU2SI5GXY.NE59I4J7IM6E@suse.com>

Hello,

On Wed May 7, 2025 at 11:20 PM -03, NIIBE Yutaka wrote:
> To disable caching, I think that you can do by:
>
> 	default-cache-ttl 0
>
Can confirm that this works.

> Possible fix to recover the same semantics would be the following.
>
> ==========================
> diff --git a/agent/cache.c b/agent/cache.c
> index e8544205f..fbe1c1f14 100644
> --- a/agent/cache.c
> +++ b/agent/cache.c
> @@ -318,6 +318,7 @@ compute_expiration (ITEM r)
>    unsigned long maxttl;
>    time_t current = gnupg_get_time ();
>    time_t next;
> +  int no_maxttl = 0;
>  
>    if (r->cache_mode == CACHE_MODE_PIN)
>      return 0; /* Don't let it expire - scdaemon explicitly flushes them.  */
> @@ -334,13 +335,16 @@ compute_expiration (ITEM r)
>      {
>      case CACHE_MODE_DATA:
>      case CACHE_MODE_PIN:
> -      maxttl = 0;  /* No MAX TTL here.  */
> +      no_maxttl = 1;
> +      /* No MAX TTL here.  */
>        break;
>      case CACHE_MODE_SSH: maxttl = opt.max_cache_ttl_ssh; break;
>      default: maxttl = opt.max_cache_ttl; break;
>      }
>  
> -  if (maxttl)
> +  if (no_maxttl)
> +    next = 0;
> +  else
>      {
>        if (r->created + maxttl < current)
>          {
> @@ -351,8 +355,6 @@ compute_expiration (ITEM r)
>  
>        next = r->created + maxttl - current;
>      }
> -  else
> -    next = 0;
>  
>    if (r->ttl >= 0 && (next == 0 || r->ttl < next))
>      {
Tested the patch but could not make it work by only setting
max-cache-ttl 0


From gniibe at fsij.org  Fri May  9 04:48:08 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 09 May 2025 11:48:08 +0900
Subject: Setting max-cache-ttl to 0 does not disable caching
In-Reply-To: <D9QZU2SI5GXY.NE59I4J7IM6E@suse.com>
References: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>
 <87tt5vdesa.fsf@haruna.fsij.org> <D9QZU2SI5GXY.NE59I4J7IM6E@suse.com>
Message-ID: <87r00yv6s7.fsf@haruna.fsij.org>

Hello, again,

Thanks for your further testing.

"Lucas Mulling" <lucas.mulling at suse.com> wrote:
> Can confirm that this works.

OK.

I wrote:
> Possible fix to recover the same semantics would be the following.

Sorry, it's not mature.

> ==========================
> -  if (maxttl)
> +  if (no_maxttl)
> +    next = 0;
> +  else
>      {
>        if (r->created + maxttl < current)

This should have been <=.


And... I modified the implementation, so that it will be easier to
maintain.


Attached a updated patch with documentation update.

The behavior/semantics of gpg-agent with 'max-cache-ttl 0' is a bit
difficult (for me).  It currently means that it pushes an entry which
will be immediately expired.  Thus, I am going to update the
documentation for default-cache-ttl==0.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-agent-Recover-the-old-behavior-with-max-cache-ttl-0.patch
Type: text/x-diff
Size: 3736 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250509/b806f997/attachment.patch>

From wk at gnupg.org  Fri May  9 14:28:09 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 09 May 2025 14:28:09 +0200
Subject: [Announce] GnuPG 2.5.6 and Gpg4win-5-Beta190 released
Message-ID: <87ecwy7yue.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.5.6.  This release is another one in a series of public
testing releases eventually leading to a new stable version 2.6.

The main features in the 2.6 series are improvements for 64 bit Windows
and the introduction of Kyber (FIPS-203) as PQC encryption algorithm.

Other than PQC support the 2.6 series will not differ a lot from 2.4
because the majority of changes are internal to make use of newer
features from the supporting libraries.


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.5.6 (2025-05-08)
================================================
         [compared to version 2.5.5]

  * gpg: Add a flag to the filter expressions for left anchored
    substring match.  [rGc12b7d047e]

  * gpg: New list option "show-trustsig" to avoid resorting to colon
    mode for this info.  [rG41d6ae8f41]

  * gpg: New command --quick-tsign-key to create a trust signature.
    [rGd90b290f97]

  * gpg: New keygen parameter "User-Id".  [rGcfd597c603]

  * gpg: New list options "show-trustsig".  [rGrG41d6ae8f41]

  * gpg: Fix double free of internal data in no-sig-cache mode [T7547]

  * gpg: Signatures from revoked or expired keys do not anymore show
    up as missing keys.  Fixes regression in 2.5.5.  [T7583]

  * gpgsm: Extend --learn-card by an optional s/n argument.  [T7379]

  * gpgsm: Skip expired certificates when selection a certificate by
    subject.  [rG4cf83273e8]

  * card: New command "ll" as alias for "list --cards".  [rGd6ee7adebe]

  * scd: Fix posssible lockup on Windows due to a lost select
    result.  [rGa7ec3792c5]

  * scd:p15: Accept P15 cards with a zero-length label.  [rGdb25aa9887]

  * keyboxd: Use case-insensitive search for mail addresses.  [T7576]

  * dirmngr: Fix a problem in libdns related to an address change from
    127.0.0.1.  [T4021]

  * gpgconf: Fix reload and kill of keyboxd.  [T7569]

  * Fix logic for certain recsel conditions.  [rG8968e84903]

  * Add Solaris support to get_signal_name.  [T7638]

  * Fix build error of the test shell on AIX.  [T7632]

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


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

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

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

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

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.6.tar.bz2 (7997k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.6.tar.bz2.sig

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

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.6_20250508.exe (5503k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.6_20250508.exe.sig

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

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

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


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

A *Beta* version of Gpg4win, our full featured Windows installer
including this version of GnuPG as well as the Kleopatra GUI and a PDF
editor can be retrieved from here:

 https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.exe (41M)
 https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.exe.sig

with the source code at:

 https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.tar.xz (276M)
 https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta190/gpg4win-5.0.0-beta190.tar.xz.sig



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

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

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

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

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

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

     sha1sum gnupg-2.5.6.tar.bz2

   and check that the output matches the next line:

ca4502c7153ff18670668fbe687d96dc633f23bf  gnupg-2.5.6.tar.bz2
5c229b07433513f14585d1b257575b33410e3c4c  gnupg-w32-2.5.6_20250508.tar.xz
d5ba24e7f1996dc14e49d4573d73af6a4ca2f455  gnupg-w32-2.5.6_20250508.exe
ad579452ec9a2faedf025a37b0b0589ec4dadd1d  gpg4win-5.0.0-beta190.exe


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

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


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

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

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

or can be downloaded as PDF at

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

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

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

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

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


Thanks
======

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

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

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

*Thank you all*

   Your GnuPG hackers


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

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

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

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

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

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

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250509/e500f3ab/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From lucas.mulling at suse.com  Fri May  9 14:37:53 2025
From: lucas.mulling at suse.com (Lucas Mulling)
Date: Fri, 09 May 2025 09:37:53 -0300
Subject: Setting max-cache-ttl to 0 does not disable caching
In-Reply-To: <87r00yv6s7.fsf@haruna.fsij.org>
References: <D9P8ZPFHG0RN.1GQPZGW40QX1R@suse.com>
 <87tt5vdesa.fsf@haruna.fsij.org> <D9QZU2SI5GXY.NE59I4J7IM6E@suse.com>
 <87r00yv6s7.fsf@haruna.fsij.org>
Message-ID: <D9RMW312KOC4.26CM9BXC5Y5IY@suse.com>

Patch tested, thank you for the quick update!