From wk at gnupg.org Thu Jul 2 15:49:49 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Jul 2026 15:49:49 +0200 Subject: [Announce] GnuPG 2.5.21 released Message-ID: <8733y11oxu.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.21. This release adds a few new features and fixes some 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 has reached end-of-life. Thus expect no more updates for 2.4. 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.21 (2026-07-02) ================================================= [compared to version 2.5.20] * New and extended features: - gpg, gpgsm: Use partial file on decryption, remove on failure. Disable with "--compatibility-flags=no-partial-file-guard". [T7873] - gpg: Use the INT_RCP_FPR subpacket in revocation signatures. [T8252] - Create a pkgversioninfo.txt file when building using the speedo build system. * Bug fixes: - gpg: Fix potential use-after-free in batch key generation when handling the keyserver URL option. [T8277] - gpgsm: Fix regression in gpgsm_verify with expired certificates. [T8188] - gpgsm: Require a minimum tag length for GCM decryption. [rG4c7e68cf3d, CVE-2026-34182] - scd: Limit the size of returned APDU objects from faulty cards. [T8281] - scd: Fix condition to retrieve ATR. [rGca25a7a61b] - scd:openpgp: Fix regression in CHV1 retry counter byte index. [rG245330ebea] - agent: Make batch import of Kyber keys work. [T8029] - dirmngr: Add a validation check in get_dns_cert_standard. [T8303] - gpgconf: Raise an error on certain parse errors. [T8261] - Fix use of usleep in file remove function on Windows. Regression since 2.5.13. [rGab9ce5f5e7] Release-info: https://dev.gnupg.org/T8262 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.21.tar.bz2 (8156k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.21.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.21_20260702.exe (5636k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.21_20260702.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.21_20260702.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.21_20260702.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. It may however take a few days until they 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.21.tar.bz2 you would use this command: gpg --verify gnupg-2.5.21.tar.bz2.sig gnupg-2.5.21.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.21.tar.bz2, you run the command like this: sha1sum gnupg-2.5.21.tar.bz2 and check that the output matches the next line: 51fae4f4d902787624eb7047f6d3e7c263ad7690 gnupg-2.5.21.tar.bz2 2e6712f413e47bb23fb4ba5b07f9b0a6aaa266e7 gnupg-w32-2.5.21_20260702.tar.xz 65e7528baf8ec1bf83d3df56e6e9e377620f2de6 gnupg-w32-2.5.21_20260702.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/T8262 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 are provided in any case. 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 From opna2608 at protonmail.com Tue Jul 14 16:14:57 2026 From: opna2608 at protonmail.com (C. Neidahl) Date: Tue, 14 Jul 2026 14:14:57 +0000 Subject: libgpg-error 1.61: t-printf failure on powerpc64-linux Message-ID: Greetings, I am trying to build libgpg-errpr version 1.61 for big-endian powerpc64-linux with GCC 15.2.0 and run the test suite. The t-printf test is failing: t-printf: format "%.100Lf" with LDBL_MAX unexpectly did not fail FAIL: t-printf Applying bfdf7b0b7b62 (tests: Skip a test when !HAVE_LONG_DOUBLE_WIDER) does not help with this, as LDBL_MAX > DBL_MAX: checking for long double with more range or precision than double... yes long double on this platform defaults to a sum of two double values (IBM double-double), which is not an IEEE-754 compliant implementation, so LDBL_* are possibly going to be different than what you're expecting. You can check last year's changes to gnulib's lib/float.h.in and tests/test-float-h.c, and the mailing list messages from the same time, for details on this format and changes that GCC 15 & C23 brought to these definitions. Let me know if you need any more details. Have a nice day. Cosima Neidahl -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - opna2608 at protonmail.com - 0xC802C863.asc Type: application/pgp-keys Size: 1753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 583 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Wed Jul 15 10:16:30 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 15 Jul 2026 17:16:30 +0900 Subject: libgpg-error 1.61: t-printf failure on powerpc64-linux In-Reply-To: References: Message-ID: <87o6g8wtup.fsf@haruna.fsij.org> Hello, Thank you for your report. "C. Neidahl wrote: > I am trying to build libgpg-errpr version 1.61 for big-endian > powerpc64-linux with GCC 15.2.0 and run the test suite. > > The t-printf test is failing: > > t-printf: format "%.100Lf" with LDBL_MAX unexpectly did not fail > FAIL: t-printf It's also in little-endian, I suppose. How about like this? ========================== diff --git a/tests/t-printf.c b/tests/t-printf.c index b0a3f3f..31d52a5 100644 --- a/tests/t-printf.c +++ b/tests/t-printf.c @@ -469,12 +469,15 @@ check_large_float (void) show ("format \"%%.100Lf\" with DBL_MAX: ->%s<-\n", buf); gpgrt_free (buf); -# ifdef HAVE_LONG_DOUBLE_WIDER +# ifdef __powerpc64__ + if (verbose) + show ("IBM double-double - skipping LDBL_MAX test\n"); +# elif defined(HAVE_LONG_DOUBLE_WIDER) ld = LDBL_MAX; buf = gpgrt_bsprintf ("%.100Lf\n", ld); if (buf) { - fail ("format \"%%.100Lf\" with LDBL_MAX unexpectly did not fail\n"); + fail ("format \"%%.100Lf\" with LDBL_MAX unexpectedly did not fail\n"); } else if (verbose) show ("format \"%%.100Lf\" with LDBL_MAX failed as expected\n"); ========================== "IBM double-double" reminds me Matcha Azuki-Azuki in a shop of our neighborhood. It's Japanese shaved ice dessert (double amount of sweet bean paste) in summer [0]. [0] https://en.wikipedia.org/wiki/Kakig%C5%8Dri -- From jscott at posteo.net Wed Jul 15 22:07:19 2026 From: jscott at posteo.net (John Scott) Date: Wed, 15 Jul 2026 20:07:19 +0000 Subject: libgpg-error 1.61: t-printf failure on powerpc64-linux In-Reply-To: <87o6g8wtup.fsf@haruna.fsij.org> References: <87o6g8wtup.fsf@haruna.fsij.org> Message-ID: <2f02e6735fb6f518c3dea9a11755aa4cde304338.camel@posteo.net> I have a question. However, I spent longer writing this than I meant to, appending things as I figured them out, and haven't had the chance yet to test changes. I hope this will be helpful as-is. > t-printf: format "%.100Lf" with LDBL_MAX unexpectly [sic] did not fail > FAIL: t-printf I see that this message comes from here: https://repo.or.cz/libgpg-error.mirror.git/blob/HEAD:/tests/t-printf.c#l477 It appears that it's trying to ensure that gpgrt_bsprintf("%.100Lf\n", (long double)LDBL_MAX) fails. We're expecting gpgrt_bsprintf() to fail, and calling it an error that it succeeds. I see at https://repo.or.cz/libgpg-error.mirror.git/blob/HEAD:/src/estream-printf.c#l1134 (inside a static helper function named 'pr_float()') there is mention of a static buffer sized just barely big enough so gpgrt_bsprintf("%.100f", DBL_MAX) will succeed. If this limit is pushed by trying to print a larger string, it is intended that an error should be returned to the caller. Perhaps the test is trying to see that this gets caught. With IBM "double-double" arithmetic, the number of bits for the exponent is still the same, and only the significand becomes effectively larger. So despite 'long double' being "bigger" than double (with HAVE_LONG_DOUBLE_WIDER defined correctly as per [1]), it needs no more decimal digits than double does to represent its LDBL_MAX. So it seems the error is the following assumption in the test: long double being "bigger" than double means printf("%Lf", LDBL_MAX) requires a bigger buffer than printf("%f", DBL_MAX) would (this is mistaken), and since the static buffer has been sized to be exactly right for the latter, it should be too small for the former. The test is surprised that printf("%Lf", LDBL_MAX) is able to make do with the small buffer, and so the test fails. With emphasis added by me, the autoconf manual says > If the C compiler supports a working long double type with more range **or** precision than the double type, define HAVE_LONG_DOUBLE_WIDER. We have attained more precision, but not more range, but gpgrt assumes we have more range indeed. A condition would be sufficient for this to be, I think, is to see that LDBL_MAX_10_EXP is strictly greater than DBL_MAX_10_EXP (these constants being from float.h). [1] https://www.gnu.org/software/autoconf/manual/html_node/Particular-Types.html#index-AC_005fTYPE_005fLONG_005fDOUBLE_005fWIDER-1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 411 bytes Desc: This is a digitally signed message part URL: From opna2608 at protonmail.com Wed Jul 15 12:54:02 2026 From: opna2608 at protonmail.com (C. Neidahl) Date: Wed, 15 Jul 2026 10:54:02 +0000 Subject: libgpg-error 1.61: t-printf failure on powerpc64-linux In-Reply-To: <87o6g8wtup.fsf@haruna.fsij.org> References: <87o6g8wtup.fsf@haruna.fsij.org> Message-ID: > It's also in little-endian, I suppose. Well, yes and no. If usage of the VSX extension is enabled, then an IEEE-compliant 128-bit floating-point type is made available [0]. Glibc can be configured to use that type for long double, and i.e. Fedora has made that switch for its powerpc64le-linux target [1]. powerpc64-linux should be available on systems that predate the VSX extension though, so the default for those is generally still the IBM double-double. For example, the machine that I'm testing things on is an Apple Power Mac G5 from 2005, which lacks both VSX and the option to switch to little-endian mode without bricking the system. As a result of that, powerpc64le-linux is not something that I can test in any way, but I'm still *somewhat* aware of it. > +# ifdef __powerpc64__ > + if (verbose) > + show ("IBM double-double - skipping LDBL_MAX test\n"); I suppose the most exact check for this situation would have to inspect some more LDBL_* defines, otherwise 128-bit IEEE-backed long double would end up not getting checked. The GCC on my machine, after importing with C23 enabled, defines: #define __LDBL_IS_IEC_60559__ 0 #define LDBL_IS_IEC_60559 __LDBL_IS_IEC_60559__ #define __LONG_DOUBLE_IBM128__ 1 LDBL_IS_IEC_60559 of 0 indicates that the long double type does not match an IEC 60559 format (1: format, but not operation; 2: format and operation) [2]. The rest of the floating-point types have their corresponding defines at 1 on my system. By comparison, a powerpc64le-linux GCC cross toolchain on my main system gives: #define __LDBL_IS_IEC_60559__ 1 #define LDBL_IS_IEC_60559 __LDBL_IS_IEC_60559__ #define __LONG_DOUBLE_IEEE128__ 1 Doesn't seem like Clang itself implements LDBL_IS_IEC_60559, but you use gnulib, which handles that. It sets LDBL_IS_IEC_60559 to 0 with x86_64-linux Clang due to the 80-bit floating-point type, while x86_64-linux GCC sets it to 1 with the same type, so there's some discrepancies on other platforms though... So maybe: diff --git a/tests/t-printf.c b/tests/t-printf.c index b0a3f3f..79f6470 100644 --- a/tests/t-printf.c +++ b/tests/t-printf.c @@ -469,7 +469,13 @@ check_large_float (void) show ("format \"%%.100Lf\" with DBL_MAX: ->%s<-\n", buf); gpgrt_free (buf); -# ifdef HAVE_LONG_DOUBLE_WIDER +# if defined(__powerpc64__) && !LDBL_IS_IEC_60559 + if (verbose) + show ("IBM double-double - skipping LDBL_MAX test\n"); +# elif !defined(HAVE_LONG_DOUBLE_WIDER) + if (verbose) + show ("LDBL_MAX == DBL_MAX - skipping LDBL_MAX test\n"); +# else ld = LDBL_MAX; buf = gpgrt_bsprintf ("%.100Lf\n", ld); if (buf) @@ -479,9 +485,6 @@ check_large_float (void) else if (verbose) show ("format \"%%.100Lf\" with LDBL_MAX failed as expected\n"); gpgrt_free (buf); -# else - if (verbose) - show ("LDBL_MAX == DBL_MAX - skipping LDBL_MAX test\n"); # endif #endif /*HAVE_LO NG_DOUBLE*/ [0]: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html [1]: https://fedoraproject.org/wiki/Releases/36/ChangeSet#New_128-bit_IEEE_long_double_ABI_for_IBM_64-bit_POWER_LE [2]: https://github.com/gcc-mirror/gcc/blob/b77cf8f055cce3e42f09410cbbf1e4f1e196b25d/gcc/c-family/c-cppbuiltin.cc#L321-L323 -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - opna2608 at protonmail.com - 0xC802C863.asc Type: application/pgp-keys Size: 1753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 583 bytes Desc: OpenPGP digital signature URL: