From sachin.t at ibm.com  Mon Dec  1 06:05:10 2025
From: sachin.t at ibm.com (Sachin T)
Date: Mon, 1 Dec 2025 05:05:10 +0000
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87y0nr7xzt.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
Message-ID: <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>

Hello,

Thanks for reviewing the changes.

The wrapper approach worked for me.
I also wanted to mention that libgpg-error already uses EXTRA_LIBS_FOR_BUILD in its configure.ac for z/OS, so using the same method in libgcrypt would keep things consistent across both projects.

I can go with the approach you recommend.

Regards,
Sachin


From: NIIBE Yutaka <gniibe at fsij.org>
Date: Friday, 28 November 2025 at 6:51?AM
To: Sachin T <sachin.t at ibm.com>
Cc: GNU Libgcrypt Development <gnupg-devel at gnupg.org>
Subject: [EXTERNAL] Re: [PATCH libgcrypt] Add support for IBM z/OS

Hello,

I have a comment about EXTRA_LIBS_FOR_BUILD.

Sachin T wrote:
>   1.
[...]
> EXTRA_LIBS_FOR_BUILD via pkg-config/zoslib for external library linking
>   2.
[...]
> cipher/Makefile.am, doc/Makefile.am: Append $(EXTRA_LIBS_FOR_BUILD) to
> gost-s-box and yat2m link lines so build-host helper programs link
> correctly with z/OS-specific libraries during the build.

If I were developing/maintaining those packages for a POSIX-like
Operating System which needs to care about specific libraries and/or
headers, I'd consider about a compiler script to use as CC (and put
linking procedure with specific libraries into that script).  Then, I'd
specify CC=<THE_PATH_TO_THE_SCRIPT> for configure (or CC_FOR_BUILD).

Or else, it would end up to ask all software to put similar patches.

Could you please consider this approach?
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251201/b6992242/attachment-0001.html>

From gniibe at fsij.org  Tue Dec  2 07:51:45 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 02 Dec 2025 15:51:45 +0900
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <87pl8xs7em.fsf@haruna.fsij.org>

Hello, again,

Sachin T <sachin.t at ibm.com> wrote:
> Thanks for reviewing the changes.

I pushed other changes (libtool macro, longlong.h and secmem.c).
Let me have some time for configure.ac.

> The wrapper approach worked for me.

Good.  Please go ahead with the wrapper approach.

If the EXTRA_LIBS_FOR_BUILD is only for GnuPG, it would be acceptable.
My concern is that it will be for (almost) all packages you build.

> I also wanted to mention that libgpg-error already uses
> EXTRA_LIBS_FOR_BUILD in its configure.ac for z/OS, so using the same
> method in libgcrypt would keep things consistent across both projects.

I see.  If the wrapper approach will be found good, we can consider
about reverting the part of libgpg-error change.
-- 


From gniibe at fsij.org  Wed Dec  3 03:58:41 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 03 Dec 2025 11:58:41 +0900
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87pl8xs7em.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87pl8xs7em.fsf@haruna.fsij.org>
Message-ID: <87zf806zku.fsf@haruna.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Let me have some time for configure.ac.

Attached is a patch for the change of configure.ac.  If no objection,
I'll push this change to master.

It includes your changes (except the one for the EXTRA_LIBS_FOR_BUILD).

Please note that the detection of -lpthread is a bit complicated.  On
z/OS, IIUC, no -lpthread is required *and* it should not be added to the
compiler option.  On GNU/Linux, it is not required any more (with newer
glibc), but it is still OK to have -lpthread option.

Here, libgcrypt only needs to know if pthread API is available or not.
For actual linking, it uses GPG_ERROR_MT_LIBS (see tests/Makefile.am).

GPG_ERROR_MT_LIBS is from libgpg-error and it is libgpg-error which
checks pthread API more deeply and pthread linking at its build time.
It uses libgpg-error/m4/threadlib.m4 from gnulib.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Add-support-for-IBM-z-OS-fixing-lpthread-check.patch
Type: text/x-diff
Size: 2537 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251203/111749f0/attachment.patch>

From sachin.t at ibm.com  Wed Dec  3 07:39:48 2025
From: sachin.t at ibm.com (Sachin T)
Date: Wed, 3 Dec 2025 06:39:48 +0000
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87zf806zku.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87pl8xs7em.fsf@haruna.fsij.org> <87zf806zku.fsf@haruna.fsij.org>
Message-ID: <CO1PR15MB50038EFC833A061030FFA8DC97D9A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hello,

Thanks. I tested your configure.ac change on z/OS and it configures and builds cleanly here. No objection to the change

Thanks
Sachin

From: NIIBE Yutaka <gniibe at fsij.org>
Date: Wednesday, 3 December 2025 at 8:28?AM
To: Sachin T <sachin.t at ibm.com>
Cc: GNU Libgcrypt Development <gnupg-devel at gnupg.org>
Subject: [EXTERNAL] RE: [PATCH libgcrypt] Add support for IBM z/OS

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Let me have some time for configure.ac.

Attached is a patch for the change of configure.ac.  If no objection,
I'll push this change to master.

It includes your changes (except the one for the EXTRA_LIBS_FOR_BUILD).

Please note that the detection of -lpthread is a bit complicated.  On
z/OS, IIUC, no -lpthread is required *and* it should not be added to the
compiler option.  On GNU/Linux, it is not required any more (with newer
glibc), but it is still OK to have -lpthread option.

Here, libgcrypt only needs to know if pthread API is available or not.
For actual linking, it uses GPG_ERROR_MT_LIBS (see tests/Makefile.am).

GPG_ERROR_MT_LIBS is from libgpg-error and it is libgpg-error which
checks pthread API more deeply and pthread linking at its build time.
It uses libgpg-error/m4/threadlib.m4 from gnulib.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251203/84da39ee/attachment.html>

From giacomo at tesio.it  Wed Dec  3 11:38:04 2025
From: giacomo at tesio.it (Giacomo Tesio)
Date: Wed, 3 Dec 2025 11:38:04 +0100
Subject: GPGME: locate-keys: how identify that different keys were returned
 by keyservers
Message-ID: <20251203113804.21c3fe3c@hermes.development.it>

Hi, while trying to improve the usability of key lookup in Claws-Mail
with a contextual menu that let you search for pgp keys over any email,
upstream developers proposed an interesting scenario I would not know
how to handle, despite looking at the GPGME documentation.

The scenario is running "gpg --locate-keys email at example.org" with the
configured keyservers returning different keys for that email address.

While I do not know if such scenario is technically possible, and I was
unable to replicate it to test by myself (sorry), I wonder how GPGME
would behave in such situation (in particular, gpgme_get_key).

Maybe all returned keys would be added to the keyring and
GPG_ERR_AMBIGUOUS_NAME would be returned?
Or maybe GPG_ERR_AMBIGUOUS_NAME would be returned but the keyring would
stay unchanged?
Or maybe the first key returned by the keyserver "wins", and all other
keys get discarded?

In general, is this something that might happen?
And if so, how gpg handles the case?


Thanks for your help.


Giacomo


From bwalzer at 59.ca  Wed Dec  3 18:22:36 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Wed, 3 Dec 2025 11:22:36 -0600
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <20251203113804.21c3fe3c@hermes.development.it>
References: <20251203113804.21c3fe3c@hermes.development.it>
Message-ID: <aTBx3FDrY6YrpBjN@watt.59.ca>

On Wed, Dec 03, 2025 at 11:38:04AM +0100, Giacomo Tesio wrote:
> Hi, while trying to improve the usability of key lookup in Claws-Mail
> with a contextual menu that let you search for pgp keys over any email,
> upstream developers proposed an interesting scenario I would not know
> how to handle, despite looking at the GPGME documentation.
> 
> The scenario is running "gpg --locate-keys email at example.org" with the
> configured keyservers returning different keys for that email address.

In PGP world, identities are denoted with a hex number. A key
fingerprint or the shortened key ID. These identities can normally be
considered to unique. The email address on the other hand is really
just a convenience feature tacked on to the identity. It is not only
possible, but reasonably common for there to be two PGP keys with the
same email address. For example, that can happen when someone abandons
a PGP key and starts over with another one with the same email
address. So the problem seems intrinsic to me. The user will
eventually be expected to determine which key fingerprint/ID is
correct.

Bruce


From m at the13thletter.info  Thu Dec 25 21:47:15 2025
From: m at the13thletter.info (Marco Ricci)
Date: Thu, 25 Dec 2025 21:47:15 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with OpenSSH
 emulation?
Message-ID: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>

Dear GnuPG developers,

how do I arrange for gpg-agent (v2.4.8, Windows, gpg4win 4.4.1) to start
with OpenSSH emulation?  (That is, how do I instruct gpg-agent v2.4.8 to
listen on the Windows named pipe "\\.\pipe\openssh-ssh-agent"?)  Per the
manual at https://www.gnupg.org/documentation/manuals/gnupg/, this
should "simply" be "run gpg-agent with the
--enable-win32-openssh-support option", but neither the manual nor the
error and help messages from gpg-agent and gpgconf are sufficient for me
to discern how to do this.

Specifically:

   - Running `gpg-agent --enable-win32-openssh-support` in a PowerShell
     window either emits "The gpg-agent is not running for this session"
     and aborts, or if the agent is started beforehand via
     `gpg-connect-agent /bye`, then `ssh-add -l` emits "Error connecting
     to agent: No such file or directory".

   - Writing "enable-win32-openssh-support" manually into
     `C:\Users\<Username>\AppData\Roaming\gnupg\gpg-agent.conf` causes
     `gpg-agent --gpgconf-test` to complain "invalid option" on the
     respective line.  Attempting to add the option via piping
     "enable-win32-openssh-support:0:1" into
     `gpgconf --change-options gpg-agent` likewise causes gpgconf to
     complain "unknown option enable-win32-openssh-support".

   - Starting gpg-agent with only the "--enable-ssh-support" option,
     which *is* recognized by both gpg-agent and gpgconf, does not cause
     gpg-agent to listen on "\\.\pipe\openssh-ssh-agent": `ssh-add -l`
     again emits "Error connecting to agent: No such file or directory".

So, what *is* the intended way to start gpg-agent on Windows with
OpenSSH emulation? And where is it documented?

Cheers,
Marco


From wk at gnupg.org  Mon Dec 29 11:31:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 29 Dec 2025 11:31:01 +0100
Subject: Request for dev.gnupg.org account
In-Reply-To: <CAGwK=3rYjefZQ7XCZ9W3d7zVKhgjcpW_TD6eF9eO4qP0m-BX9Q@mail.gmail.com>
 (suunj via Gnupg-users's message of "Sat, 27 Dec 2025 11:49:06 +0900")
References: <CAGwK=3rYjefZQ7XCZ9W3d7zVKhgjcpW_TD6eF9eO4qP0m-BX9Q@mail.gmail.com>
Message-ID: <87qzsdpoka.fsf@jacob.g10code.de>

On Sat, 27 Dec 2025 11:49, suunj said:
> Hello, I would like to request an account on dev.gnupg.org to report bugs
> and contribute to the project.

Confirmation mal is on the way.


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/20251229/98efee05/attachment.sig>

From wk at gnupg.org  Mon Dec 29 11:50:38 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 29 Dec 2025 11:50:38 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info> (Marco
 Ricci via Gnupg-devel's message of "Thu, 25 Dec 2025 21:47:15 +0100")
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
Message-ID: <87ms31pnnl.fsf@jacob.g10code.de>

Hi!

Regarding OpenSSH support on Windows please checkout 
https://dev.gnupg.org/T3883

I have no first hand experience but the last comment on the ticket might
help you:

In case if someone finds it through a search:

After adding enable-win32-openssh-support to gpg-agent.conf, need to
specify the path to connect gpg-agent just add/check lines in OpenSSH
config file:

IdentityAgent "\\\\.\\pipe\\openssh-ssh-agent"
IdentityFile none

or set env:

set SSH_AUTH_SOCK=\\.\pipe\openssh-ssh-agent

in Git config:

[core]
	sshCommand = "'C:/OpenSSH/SSH.exe' -F C:/OpenSSH/config -v"

MinGit requires the full path to the OpenSSH executable, otherwise 'SSH'
evokes bundled in MinGit, but it can't work with any method to connect
gpg-agent.


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/20251229/03736248/attachment.sig>

From wk at gnupg.org  Mon Dec 29 12:05:34 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 29 Dec 2025 12:05:34 +0100
Subject: How to start gpg-agent v2.4.8 on Windows (gpg4win 4.4.1) with
 OpenSSH emulation?
In-Reply-To: <87ms31pnnl.fsf@jacob.g10code.de> (Werner Koch via Gnupg-devel's
 message of "Mon, 29 Dec 2025 11:50:38 +0100")
References: <a3a957c72e1b60612d6ae1d86a2b02d2@the13thletter.info>
 <87ms31pnnl.fsf@jacob.g10code.de>
Message-ID: <87ikdppmyp.fsf@jacob.g10code.de>

Hi

I forgot to mention that you start gpg-agent and thus ssh support using

  gpgconf --launch gpg-agent

or just use "gpg -K" which launches the gpg-agent as a side-effect.


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/20251229/ff6c4654/attachment.sig>

From wk at gnupg.org  Tue Dec 30 09:40:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 30 Dec 2025 09:40:01 +0100
Subject: [Announce] GnuPG 2.5.16 released
Message-ID: <87qzscs6qm.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
Version 2.5.16.  This release adds new features and fixes a couple of
bugs.

Note that the 2.5 series is now declared the stable version of GnuPG.
The oldstable 2.4 series will reach end-of-life in just 6 months.

The main features in the 2.5 series are improvements for 64 bit Windows
and the introduction of Kyber (aka ML-KEM or 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.16 (2025-12-30)
=================================================
         [compared to version 2.5.14]
         
  * gpg: Fix a validation bug when using keyboxd.  [T7983]

  * gpg: Deprecate the option --not-dash-escaped and ignore the
    NotDashEscaped armor header.  [T7901]

  * keyboxd: Fix migration to new schema.  [T7892,rG81bb949755]

  * dirmngr: New compatibility flag "ocsp-sha256-certid" to support
    forthcoming libksba versions.  [rG674aa54242]

  * Use a synchronous spawning method for the daemon processes under
    Windows.  [T7716]

  * Avoid the function name thread_init to fix building on AIX.
    [T7958]

  * New translation to Georgian.

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



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.16.tar.bz2 (8109k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.16.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.16_20251230.exe (5571k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.16_20251230.exe.sig

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

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

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


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

We also provide Debian style packages for a couple of Debian variants.
See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch
to other distros/releases.  If you encounter packaging problems please
report them to the gnupg-devel mailing list.  Due to the holidays it may
take a few days until the packages are available.


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

A new beta version of Gpg4win is this time not available.  Please wait
for the upcoming Gpg4win 5.0 release.



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.16.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.16.tar.bz2.sig gnupg-2.5.16.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.16.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.16.tar.bz2

   and check that the output matches the next line:

3acefeef08c82a4d4a8ba36f95c2986fb925d359  gnupg-2.5.16.tar.bz2
94cd33c1fb6ca8191f582afbdba8fcc7c1b04b5b  gnupg-w32-2.5.16_20251230.tar.xz
250e1d3c3b4924188e6457a4c1f0d33ff2b2fe9e  gnupg-w32-2.5.16_20251230.exe


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

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, Georgian, 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.

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

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

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

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


Thanks
======

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

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

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

*Thank you all*

   Your GnuPG hackers


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

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

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)
  
    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)
  
    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)
  
    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

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

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

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

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

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

From marius.spix at web.de  Tue Dec 30 14:28:50 2025
From: marius.spix at web.de (Marius Spix)
Date: Tue, 30 Dec 2025 14:28:50 +0100
Subject: Unsafe configuration of the pinentry program
Message-ID: <20251230142850.10e73989@rockhopper>

Dear GnuPG devs,

I wanted to point out a potential security concern about gpg-agent.

I noted that an application with write access to an user's home
directory can easily compromise gpg-agent by overriding the key
pinentry-program in ~/.gnupg/gpg-agent.conf

This is a potential security risk, as it allows to switch the pinentry
plugin with a malicious version, which can be uses to steal passwords.

I am not aware whether this vulnerability has ever been
exploited, but it would be trivial to do so. Therefore, I wonder why no
hardening mechanisms are used here.

In my opinion there should be additional checks, e. g. a restriction of
allowed pinentry paths (e. g. only /usr/bin and /usr/local/bin),
ownership checks (e. g. only allow binaries owned by root) or
warnings, when a non-standard pinentry-program setting is used. What do
you think?

Thank you very much for your time and for maintaining GnuPG.

Best regards

Marius Spix