From me at maiyun.me Sat May 2 14:06:15 2026 From: me at maiyun.me (Zhang Maiyun) Date: Sat, 2 May 2026 08:06:15 -0400 Subject: [PATCH] build: Add AC_PROG_AR to configure.ac In-Reply-To: <20260502120128.89949-1-me@maiyun.me> References: <20260502120128.89949-1-me@maiyun.me> Message-ID: <202605029f94b93c2900@localnet.as211585.net> Hello all, I apologize for another trivial patch. This makes sure cross compilations use the correct `ar`. While previously `ar`/`ranlib` seemed to silently accept objects for another architecture, now, Darwin `ar` (macOS) discards unrecognized objects and causes the `libsecmem.a`/`libpinentry.a` linking steps to fail during a cross compilation: ``` $ aarch64-linux-gnu-gcc -c -o test.o -x c - <<< 'void f(){}' $ ar cr test.a test.o ranlib: warning: archive member 'test.o' not a mach-o file $ nm test.a $ ar t test.a __.SYMDEF SORTED ``` On Sat, May 02, 2026 at 08:01:20AM -0400, me at maiyun.me wrote: > From: Zhang Maiyun > > * configure.ac: add AC_PROG_AR. > > -- > > Signed-off-by: Zhang Maiyun > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index a4f443d..3df11b3 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) > AC_PROG_CC > AC_PROG_CPP > AC_PROG_INSTALL > +AC_PROG_AR > AC_PROG_RANLIB > # We need to check for cplusplus here because we may not do the test > # for Qt and autoconf does does not allow that. > -- > 2.54.0 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 325 bytes Desc: not available URL: From me at maiyun.me Sat May 2 14:12:16 2026 From: me at maiyun.me (Zhang Maiyun) Date: Sat, 2 May 2026 08:12:16 -0400 Subject: [PATCH pinentry] build: Add AC_PROG_AR to configure.ac In-Reply-To: <202605029f94b93c2900@localnet.as211585.net> References: <20260502120128.89949-1-me@maiyun.me> <202605029f94b93c2900@localnet.as211585.net> Message-ID: <202605020267ce26373b@localnet.as211585.net> Apologies. I did not mention that this patch is for pinentry. GnuPG already has `AC_CHECK_TOOL(AR, ar, :)`. On Sat, May 02, 2026 at 08:06:48AM -0400, Zhang Maiyun wrote: > Hello all, > > I apologize for another trivial patch. > > This makes sure cross compilations use the correct `ar`. > > While previously `ar`/`ranlib` seemed to silently accept objects for > another architecture, now, Darwin `ar` (macOS) discards unrecognized > objects and causes the `libsecmem.a`/`libpinentry.a` linking steps to > fail during a cross compilation: > > ``` > $ aarch64-linux-gnu-gcc -c -o test.o -x c - <<< 'void f(){}' > $ ar cr test.a test.o > ranlib: warning: archive member 'test.o' not a mach-o file > $ nm test.a > > $ ar t test.a > __.SYMDEF SORTED > ``` > > On Sat, May 02, 2026 at 08:01:20AM -0400, me at maiyun.me wrote: > > From: Zhang Maiyun > > > > * configure.ac: add AC_PROG_AR. > > > > -- > > > > Signed-off-by: Zhang Maiyun > > --- > > configure.ac | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configure.ac b/configure.ac > > index a4f443d..3df11b3 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) > > AC_PROG_CC > > AC_PROG_CPP > > AC_PROG_INSTALL > > +AC_PROG_AR > > AC_PROG_RANLIB > > # We need to check for cplusplus here because we may not do the test > > # for Qt and autoconf does does not allow that. > > -- > > 2.54.0 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 325 bytes Desc: not available URL: From me at maiyun.me Sat May 2 14:01:20 2026 From: me at maiyun.me (me at maiyun.me) Date: Sat, 2 May 2026 08:01:20 -0400 Subject: [PATCH] build: Add AC_PROG_AR to configure.ac Message-ID: <20260502120128.89949-1-me@maiyun.me> From: Zhang Maiyun * configure.ac: add AC_PROG_AR. -- Signed-off-by: Zhang Maiyun --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index a4f443d..3df11b3 100644 --- a/configure.ac +++ b/configure.ac @@ -81,6 +81,7 @@ AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) AC_PROG_CC AC_PROG_CPP AC_PROG_INSTALL +AC_PROG_AR AC_PROG_RANLIB # We need to check for cplusplus here because we may not do the test # for Qt and autoconf does does not allow that. -- 2.54.0 From andrewg at andrewg.com Sun May 3 14:17:24 2026 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 3 May 2026 13:17:24 +0100 Subject: No v5 support in hockeypuck (Was: Undocumented novel Ed448 point encoding breaks interoperability) In-Reply-To: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> References: <4e12f3b7-3a6c-41b8-8f8d-83a89db9da63@andrewg.com> Message-ID: Hi, all. In reply to my previous email to gnupg-devel [0], but cross-posting for maximum audience: On 05/01/2026 13:55, Andrew Gallagher via Gnupg-devel wrote: > It has been brought to my attention that Ed448 keys are being encoded > without prefix octets in their MPIs/SOSes, which breaks compatibility > with go-crypto (and perhaps others) and is not documented anywhere that > I can find. The librepgp specification requires prefix octets for all > ECC curve point representations. After (finally!) enabling support for v5 keys in hockeypuck, I have discovered that ECDH curve448 encryption subkeys have the same curve point encoding issue as Ed448 signing (sub)keys. protonmail/go-crypto, the OpenPGP library that hockeypuck relies on, implemented v5 support according to the latest rfc4880bis [1] draft, which consistently specifies prefix octets of 0x04 or 0x40 for all ECC point curves, whether ECDSA, ECDH, or EdDSA. (protonmail/go-crypto was an early adopter of the rfc4880bis draft, and as such it is the only library available to hockeypuck that provides production v5 support of any kind; most of the alternatives never officially released v5 support) The change in the Ed448 point encoding since rfc4880bis, as mentioned in my previous email, has been (belatedly) acknowledged in the most recent version of draft-librepgp [2]. The discrepancy in the ECDH point encoding still has not. As a result, it is not now possible for hockeypuck to process *any* v5 key material that GnuPG generates, even if we include support for the v5 packet format as planned, since v5 is only generated in practice for x448 and type 8 kyber algorithms, neither of which are parseable. Note also that x448 key generation is gated behind expert mode in gnupg and type 8 "kyber" keys are not. This means that only a small fraction of the wild population of v5 keys would be fully usable even if this encoding discrepancy was addressed. Type 8 will not be implemented in pm/gc as the library is prioritising support for the upcoming standard draft-ietf-openpgp-pqc [3] and draft-ietf-openpgp-nist-bp-comp [4] PQC keys instead. At this point, even though it would be easy for me to claim a theoretical "v5 support" in hockeypuck 2.4, it would be a cruel and misleading prank on our users because none of them would be able to upload a real v5 key to any of the keyservers. Even if we were to patch in a hotfix for prefix-less code points (which would not be prohibitively difficult) it would still only serve a small number of expert users, and expert users are much more likely to prefer PQC encryption. So I am (as of today) dropping v5 support as a design goal of hockeypuck, and pausing work on it indefinitely. If and when a meaningful fraction of GnuPG-compatible algorithm code points are added to pm/gc, or if GnuPG added support for interoperable PQC algorithms [3][4], I would happily reconsider. I'm sorry that it has taken me three years to come to this conclusion. I could (in theory) have spotted this incompatibility earlier and saved users the false hope that v5 and v6 keys could coexist on the keyservers in the current state of the ecosystem. Thanks once again to Liz Fong-Jones for finding this issue and bringing it to my attention. A [0] https://lists.gnupg.org/pipermail/gnupg-devel/2026-January/036128.html [1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis#name-ecdsa-and-ecdh-conversion-p [2] https://author-tools.ietf.org/iddiff?url1=draft-koch-librepgp-04&url2=draft-koch-librepgp-05&difftype=--html#part-10 [3] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc [4] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp PS here's a hexdump of a v5 curve448 ECDH subkey that I generated this morning using gnupg 2.5.18 from macports, showing that there is no 0x40 or 0x04 octet present. The prefix octet would be expected at byte 0x12, immediately following the x448 curve OID 0x2b656f and the MPI length 0x01be. (It's an MPI length BTW, not an SOS length - SOS lengths are rounded up to the nearest multiple of 8) ``` 00000000 b8 CTB 00000001 4c length 00000002 05 version 00000003 69 f7 0a 31 12 00 00 00 42 03 2b 65 6f 00000010 01 be 37 69 62 e9 a7 a7 81 c5 7b c5 c7 5d da f6 00000020 d2 aa 26 e1 7e fc 35 ce 3c 11 d9 50 b9 c9 71 84 00000030 5d 61 60 84 93 af 60 fa db 59 aa 15 68 b4 3f 65 00000040 cd 1d fc 3d d6 34 c3 64 1a 49 03 01 0a 09 ``` From jernej.jakob at gmail.com Tue May 5 11:51:44 2026 From: jernej.jakob at gmail.com (Jernej Jakob) Date: Tue, 5 May 2026 11:51:44 +0200 Subject: Pinentry-mode loopback doesn't tell the user which PIN it's asking for Message-ID: <20260505115144.3abae0c6@gentoo.home> I have a GUI-less system that I use gpg on, I use it in GNU screen, I tried to set it to use pinentry-tty but that conflicts with screen and it breaks input (IIRC it doubles all characters or is otherwise unusable, it's been a while since I tested it). It works fine with pinentry-mode=loopback, but it doesn't say which PIN it's asking for, so I have to work from memory, knowing which PIN it's asking for which particular command. Is it possible to make gpg say which PIN it's asking for, the same way that pinentry does? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 265 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue May 5 13:45:17 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 May 2026 13:45:17 +0200 Subject: Pinentry-mode loopback doesn't tell the user which PIN it's asking for In-Reply-To: <20260505115144.3abae0c6@gentoo.home> (Jernej Jakob via Gnupg-devel's message of "Tue, 5 May 2026 11:51:44 +0200") References: <20260505115144.3abae0c6@gentoo.home> Message-ID: <871pfqqdv6.fsf@jacob.g10code.de> On Tue, 5 May 2026 11:51, Jernej Jakob said: > It works fine with pinentry-mode=loopback, but it doesn't say which PIN That is a kludge for unattended use. > Is it possible to make gpg say which PIN it's asking for, the same way > that pinentry does? No, it does not know. gpg-agent knows that. Either you write your own pinentry in a simialr manner as Emacs did it. Or if you have no GUI, just use a curses based Pinentry or the pinentry-tty. The curses mode is actually the fallback for the GUI pinentries if DISPLAY is not set. You may need to redraw the screen, as it is the case with many curses applications, but gpg supports this by emitting a PINENTRY_LAUNCHED status line. 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: From bernhard at intevation.de Thu May 7 16:46:50 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 7 May 2026 16:46:50 +0200 Subject: python-gpg 2.0.0 from gpgmepy.git on pypi Message-ID: <202605071646.51045.bernhard@intevation.de> Python developers can now find and download https://pypi.org/project/gpg/2.0.0/ Thanks for Paul Schwabauer (previously Intevation) for preparations and John Rouillard (roundup-tracker.org) for some testing. The release is most likely suboptimal, but as the last upload there was from 2018, I've decided to at least improve the situation and upload what we have. Devs can at least see that newer python bindings exist. Werner, I've put in a branch `pypi-pub-process` with a Dockerfile to document and make the process more repeatable. Is it okay to merge this with the main branch? Tech: The python module is build from libgpgme-dev on Debian GNU/Linux, which is 1.24.2-3. But no binary wheel is shipped (this time). Is it okay to build it from there? (I guess it is, but I am unsure.) All: python-gpg -- the gpgme-python bindings for GnuPG - need help with maintenance. (I am just the interims maintainer.) Please approach me if you can and want to help! Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri May 8 11:43:44 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 08 May 2026 11:43:44 +0200 Subject: python-gpg 2.0.0 from gpgmepy.git on pypi In-Reply-To: <202605071646.51045.bernhard@intevation.de> (Bernhard Reiter via Gnupg-devel's message of "Thu, 7 May 2026 16:46:50 +0200") References: <202605071646.51045.bernhard@intevation.de> Message-ID: <873402nsmn.fsf@jacob.g10code.de> On Thu, 7 May 2026 16:46, Bernhard Reiter said: > Werner, > I've put in a branch `pypi-pub-process` with a Dockerfile to document > and make the process more repeatable. Is it okay to merge this with the main > branch? I have no idea about the Python support; I thought you take care about it. 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: From bernhard at intevation.de Fri May 8 12:28:52 2026 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 8 May 2026 12:28:52 +0200 Subject: gpgmepy Maintainer (needed) Re: python-gpg 2.0.0 from gpgmepy.git on pypi In-Reply-To: <873402nsmn.fsf@jacob.g10code.de> References: <202605071646.51045.bernhard@intevation.de> <873402nsmn.fsf@jacob.g10code.de> Message-ID: <202605081228.59191.bernhard@intevation.de> Am Freitag 08 Mai 2026 11:43:44 schrieb Werner Koch via Gnupg-devel: > On Thu, 7 May 2026 16:46, Bernhard Reiter said: > > Werner, > > I've put in a branch `pypi-pub-process` with a Dockerfile to document > > and make the process more repeatable. Is it okay to merge this with the > > main branch? > > I have no idea about the Python support; This was a general question if you had reservations against using Dockerfile as a specific way to document the needed technical steps for publication. I understand that this is not the case. - thanks. [gpgmepy Maintainership] > I thought you take care about it. As explained in March 2025 on this list: I am doing some interims maintainership with Intevation. So gpgmepy is still looking for more contributors and a new maintainer! For the meantime, the goal was to get the current existing bindings at least published on pypi for visibility and to support other python devs at little bit. Paul Schwabauer was doing most of the work, but he left Intevation last fall. So it took me a while to get it done (until yesterday). For the GnuPG ecosystem I believe that supporting bindings and other devs using them, e.g. from the python community, is really helpful. Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From whame at whame.dev Fri May 8 17:07:09 2026 From: whame at whame.dev (Waqar Hameed) Date: Fri, 08 May 2026 15:07:09 +0000 Subject: [PATCH] agent: Fix not using cache for pinentry loopback Message-ID: <87o6iqq6sm.a.out@whame.dev> * agent/command.c (cmd_get_passphrase): Use a local copy of cacheid. -- Using the passphrase cache with pinentry loopback mode doesn't work. This is due to `cacheid` being wiped by `assuan_begin/end_confidential()` in `pinentry_loopback()`. This results in calling `agent_put_cache()` with `cacheid` pointing to a buffer with all zeros (and thus an empty string). Fix this by making a local copy of `cacheid` before calling `agent_get_passphrase()`. This way `cacheid` is guaranteed to point to valid (untouched) data both during cache look up and update. Signed-off-by: Waqar Hameed --- This was working fine on my Debian 12 system (gpg version 2.2.40) and broke when upgrading to Ubuntu 24.04 (gpg version 2.4.4). I haven't done a git bisect to really understand how/when this occurred (mostly due to difficulties building with different versions of the dependency libraries). Also, a search on the internet reveals that many others have reported this in various forums. As far as I can see no one really fixed this for all these years. It got too annoying for me, I had to roll up my sleeves and debug it myself :) agent/command.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/agent/command.c b/agent/command.c index 21c95203c..644c30672 100644 --- a/agent/command.c +++ b/agent/command.c @@ -2023,8 +2023,8 @@ cmd_get_passphrase (assuan_context_t ctx, char *line) char *pw; char *response = NULL; char *response2 = NULL; - char *cacheid = NULL; /* May point into LINE. */ - char *desc = NULL; /* Ditto */ + char *cacheid = NULL; + char *desc = NULL; /* May point into LINE. */ char *prompt = NULL; /* Ditto */ char *errtext = NULL; /* Ditto */ const char *desc2 = _("Please re-enter this passphrase"); @@ -2088,6 +2088,8 @@ cmd_get_passphrase (assuan_context_t ctx, char *line) * the cache. */ if (ctrl->restricted || !strcmp (cacheid, "X")) cacheid = NULL; + else + cacheid = xstrdup(cacheid); if (!strcmp (errtext, "X")) errtext = NULL; if (!strcmp (prompt, "X")) @@ -2282,6 +2284,7 @@ cmd_get_passphrase (assuan_context_t ctx, char *line) xfree (entry_errtext); xfree (pi2); xfree (pi); + xfree (cacheid); return leave_cmd (ctx, rc); } -- 2.43.0 From gniibe at fsij.org Tue May 12 06:57:38 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 May 2026 13:57:38 +0900 Subject: [PATCH pinentry] build: Add AC_PROG_AR to configure.ac In-Reply-To: <202605020267ce26373b@localnet.as211585.net> References: <20260502120128.89949-1-me@maiyun.me> <202605029f94b93c2900@localnet.as211585.net> <202605020267ce26373b@localnet.as211585.net> Message-ID: <87tssdxm0t.fsf@haruna.fsij.org> Hello, Zhang Maiyun wrote: > I did not mention that this patch is for pinentry. Thank you for the patch. Applied and pushed to pinentry master. -- From gniibe at fsij.org Wed May 13 07:38:38 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 13 May 2026 14:38:38 +0900 Subject: [PATCH] agent: Fix not using cache for pinentry loopback In-Reply-To: <87o6iqq6sm.a.out@whame.dev> References: <87o6iqq6sm.a.out@whame.dev> Message-ID: <87y0hnswbl.fsf@haruna.fsij.org> Hello, Waqar Hameed wrote: > * agent/command.c (cmd_get_passphrase): Use a local copy of cacheid. Thank you for your patch. Applied and pushed to master. I found another place to be fixed, it's also fixed in master. > This was working fine on my Debian 12 system (gpg version 2.2.40) and > broke when upgrading to Ubuntu 24.04 (gpg version 2.4.4). I haven't done > a git bisect to really understand how/when this occurred (mostly due to > difficulties building with different versions of the dependency > libraries). It is libassuan 2.5.6 which introduced wiping the memory for confidential inquery. In Debian 12, it's 2.5.5. -- From wk at gnupg.org Wed May 13 15:14:27 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 May 2026 15:14:27 +0200 Subject: [Announce] GnuPG 2.5.20 released Message-ID: <87wlx7jvt8.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.20. This release adds two features to gpgsm and fixes a some minor security bugs. 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. Note that the old 2.4 series reaches end-of-life in just 6 week. Thus update to 2.5.20 in time. As always with GnuPG, new versions are fully compatible with previous versions. 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.20 (2026-05-13) ================================================= [compared to version 2.5.19] * New and extended features: - gpgsm: Implement GCM encryption. Note that decryption works since version 2.3.2. [T3979] - gpgsm: New option --attribute and server command SETATTR to include arbitrary signed or unsigned attributes into a signature. Enable only with libksba 1.7.0 or later. [T4537] - gpgsm: Introduce system attribute _signingCertificateV2. [rG0335a9cb04] * Bug fixes: - gpg: Fix wrong assertion failure which could very rarely occur during key signature checking. [rG693f5642f6] - gpg: Consider certify-only keys for revocation signature check. [T8196] - gpgsm: Fix possible double free in the CMS parser. [T8240] - gpgsm: Fix possible too early removal of ephemeral keys. [T8236] - gpgsm: Avoid emitting a final FAILURE status line if --status-fd is not used. [rG69c27fe377] - gpgsm: Fix a regression in 2.5.19 for password encrypted GCM data. [rG60a823c97b] - agent: Fix not using cache for pinentry loopback. [rGd4b608a31f] - agent: Fix command PUT_SECRET by saving input line. [rG1875bc185e] - keyboxd: Mark keys searched but not imported via LDAP correctly as ephemeral. [T8048] - scdaemon: Avoid buffer overflow with SC-HSM cards providing RSA keys > 2k. [T8244] - dirmngr: Fix uninitialized use of the dns_any union in dns_rr_cmp. [T8251] Release-info: https://dev.gnupg.org/T7997 Getting the Software ==================== Please follow the instructions found at 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 . 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.20.tar.bz2 (8132k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.20.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.20_20260513.exe (5631k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.20_20260513.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.20_20260513.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.20_20260513.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 holiday tomorrow it may take a few days until new packages are available. Windows Installer ================= A new version of Gpg4win is in planning. For those who are affected by one of the now fixed bugs, it is possible to install the simple Windows installer mentioned above on top of gpg4win 5.0.2. 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.20.tar.bz2 you would use this command: gpg --verify gnupg-2.5.20.tar.bz2.sig gnupg-2.5.20.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.20.tar.bz2, you run the command like this: sha1sum gnupg-2.5.20.tar.bz2 and check that the output matches the next line: 96371ec0260da5a22edbf8e4d3bf0e54b3ea5b8e gnupg-2.5.20.tar.bz2 a8e1b948766d82430d9fd0f22f05f776973614ee gnupg-w32-2.5.20_20260513.tar.xz 6353c4a98c07b29250ce21ba0321e0d2abd7d1cb gnupg-w32-2.5.20_20260513.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 and maybe https://gnupg.com/20260122-39C3_reply_gpg_fail.html In case of build problems specific to this release please first check https://dev.gnupg.org/T7997 for updated information. We are sorry that due to ongoing DoS on this service, you may end up at a "is under maintenance page". Static copies of the ticket pages will soon be provided, though. 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. * 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 See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. * List of Release Signing Keys: To guarantee that a downloaded 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 five 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) brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23] 1493 269D E61F 124A A69A 316E 3ADF 34EB DBB2 00A4 GnuPG.com (Release Signing Key 2026) 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 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: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce