From r.bartel at gmx.net Fri Apr 15 18:47:27 2022 From: r.bartel at gmx.net (Robert Bartel) Date: Fri, 15 Apr 2022 18:47:27 +0200 Subject: [PATCH gnupg] g10/import.c: ignore too large signature packets Message-ID: Hello list, I recently noticed a denial of service against the German eID certification public key from Governikus (https://pgp.governikus.de) on the keyserver hkps://keyserver.ubuntu.com: Trying to import it from the keyserver with GnuPG 2.3.4 fails due to a too large signature packet, which can be reproduced with: gpg -vv --recv-keys 0x5E5CCCB4A4BF43D7 At the end of the output of this command you can see a signature packet with a misused policy url field carrying a so called improvement suggestion in German. This packet is followed by another one which includes hashed data exceeding the arbitrary size limit of 10000 bytes from g10/parse-packet.c line 2140, leading to the import error of: gpg: signature packet: hashed data too long gpg: read_block: read error: Invalid packet gpg: no valid OpenPGP data found. gpg: Total number processed: 0 A better behavior, instead of failing the public key import, would be to just ignore too large signature packets. This can be achieved with the attached trivial patch of g10/import.c. It allows the import to succeed with the "signature packet: hashed data too long" warning. I hope it does not introduce new problems in the code, like missing self signatures when they are too large (will the import fail or lead to an invalid imported public key?). Maybe someone with more insight into the matter can also think of other possible DoS scenarios, like other maliciously large packet types or similar, which should additionally be handled at this point of the code. Please consider applying the patch upstream or making equivalent changes to the code, to get GnuPG more DoS resistant in the future. Thank you, Robert -------------- next part -------------- diff -urd gnupg-2.3.4/g10/import.c gnupg-2.3.4-patched/g10/import.c --- gnupg-2.3.4/g10/import.c 2021-11-12 16:13:51.000000000 +0100 +++ gnupg-2.3.4-patched/g10/import.c 2022-04-15 18:07:02.632703389 +0200 @@ -995,8 +995,9 @@ } else if (gpg_err_code (rc) == GPG_ERR_INV_PACKET && (pkt->pkttype == PKT_OLD_COMMENT - || pkt->pkttype == PKT_COMMENT)) - ; /* Ignore too large comment packets. */ + || pkt->pkttype == PKT_COMMENT + || pkt->pkttype == PKT_SIGNATURE)) + ; /* Ignore too large comment and signature packets. */ else { log_error("read_block: read error: %s\n", gpg_strerror (rc) ); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: not available URL: From wk at gnupg.org Thu Apr 21 18:15:50 2022 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Apr 2022 18:15:50 +0200 Subject: [Announce] GnuPG 2.3.5 released Message-ID: <87o80ubefd.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.3.5. This is another release in the stable 2.3 series which introduces new options, improves the performance, and fixes some bugs. See below for details. 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. Three different series of GnuPG are actively maintained: - Version 2.3 is the current stable version with a lot of new features compared to 2.2. This announcement is about the latest release of this series. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is only maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Noteworthy changes in version 2.3.5 (2022-04-21) ================================================ * gpg: Up to five times faster verification of detached signatures. Doubled detached signing speed. [T5826,rG4e27b9defc,rGf8943ce098] * gpg: Threefold decryption speedup for large files. [T5820,rGab177eed51] * gpg: Nearly double the AES256.OCB encryption speed. [rG99e2c178c7] * gpg: Removed EAX from the preference list. [rG253fcb9777] * gpg: Allow --dearmor to decode all kinds of armor files. [rG34ea19aff9] * gpg: Remove restrictions for the name part of a user-id. [rG8945f1aedf] * gpg: Allow decryption of symmetric encrypted data even for non-compliant cipher. [rG8631d4cfe2] * gpg,gpgsm: New option --require-compliance. [rGee013c5350] * gpgsm: New option --ignore-cert-with-oid. [rGe23dc755fa] * gpgtar: Create and handle extended headers to support long file names. [T5754] * gpgtar: Support file names longer than MAX_PATH on Windows. [rG70b738f93f] * gpgtar: Use a pipe for decryption and thus avoid memory exhaustion. [rGe5ef5e3b91] * gpgtar: New option --with-log. [rGed53d41b4c] * agent: New flag "qual" for the trustlist.txt. [rG7c8c606061] * scdaemon: Add support for GeNUA cards. [rG0dcc249852] * scdaemon: Add --challenge-response option to PK_AUTH for OpenPGP cards. [T5862] * dirmngr: Support the use of ECDSA for CRLs and OCSP. [rGde87c8e1ea,rG890e9849b5] * dirmngr: Map all gnupg.net addresses to the Ubuntu keyserver. [T5751] * ssh: Return a faked response for the new session-bind extension. [T5931] * gpgconf: Add command aliases -L -K -R. [rGec4a1cffb8] * gpg: Request keygrip of key to add via command interface. [T5771] * gpg: Print Yubikey version correctly. [T5787] * gpg: Always use version >= 4 to generate key signature. [T5809] * gpg: Fix generating AEAD packet. [T5853] * gpg: Fix version on symmetric encrypted AEAD files if the force option is used. [T5856] * gpg: Fix adding the list of ultimate trusted keys. [T5742] * gpgsm: Fix parsing of certain PKCS#12 files. [T5793] * gpgsm: Print diagnostic about CRL problems due to Tor mode. [rG137e59a6a5] * agent: Use "Created:" field for creation time. [T5538] * scdaemon Fix error handling for a PC/SC reader selected with reader-port. [T5758] * scdaemon: Fix DEVINFO with no --watch. [rGc6dd9ff929] * scdaemon: Fix socket resource leak on Windwos. [T5029] * scdaemon: Use extended mode for pkcs#15 already for rsa2048. [rG597253ca17] * scdaemon: Enhance PASSWD command to accept KEYGRIP optionally. [T5862] * scdaemon: Fix memory leak in ccid-driver. [rG8ac92f0e80] * tpm: Always use hexgrip when storing a key password. [rGaf2fbd9b01] * dirmngr: Make WKD lookups work for resolvers not handling SRV records. [T4729] * dirmngr: Avoid initial delay on the first keyserver access in presence of --no-use-tor. [rG57d546674d] * dirmngr: Workaround for a certain broken LDAP URL. [rG90caa7ad59] * dirmngr: Escape more characters in WKD requests. [T5902] * dirmngr: Suppress error message on trial reading as PEM format. [T5531] * gpgconf: Fix component table when not building without TPM support. [T5701] * gpgconf: Silence warnings from parsing the option files. [T5874] * gpgconf: Do not list ignored options and mark forced options as read-only. [rG42785d7c8a] * gpgconf: Tweak the use of the ldapserver option. [T5801] * ssh: Fix adding an ed25519 key with a zero length comment. [T5794] * kbx: Fix searching for FPR20 in version 2 blob. [T5888] * Fix early homedir creation. [T5895] * Improve removing of stale lockfiles under Unix. [T5884] Release-info: https://dev.gnupg.org/T5743 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 FTP 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.3.5.tar.bz2 (7423k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.5.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.3.5_20210421.exe (4717k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.5_20210421.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. 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.3.5.tar.bz2 you would use this command: gpg --verify gnupg-2.3.5.tar.bz2.sig gnupg-2.3.5.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.3.5.tar.bz2, you run the command like this: sha1sum gnupg-2.3.5.tar.bz2 and check that the output matches the next line: 0b9f3dc3cb5972844a18fc9b692730e53ffd55a5 gnupg-2.3.5.tar.bz2 3c020bce4e8b6da69e3a31d6fc3745a8c2263319 gnupg-w32-2.3.5_20220421.tar.xz ad98967bde94ef57b55d60d167d884bcea3e65d6 gnupg-w32-2.3.5_20220421.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, 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/T5743 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. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. Fortunately, and this is still not common with free software, we have now 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 trademark 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 helping 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) 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. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 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 taviso at gmail.com Fri Apr 22 00:19:21 2022 From: taviso at gmail.com (Tavis Ormandy) Date: Thu, 21 Apr 2022 22:19:21 -0000 (UTC) Subject: crash importing truncated subkeys Message-ID: Hello, I noticed that if there are two opaque identical public subkey packets, but one is truncated, gpg crashes on import in gcry_mpi_cmp() I just did this to repro: $ gpgcompose --public-key taviso --public-subkey taviso \ --user-id anything --public-subkey taviso \ | perl -p -e 's/(\xb9..\x04....)\x01/\1\xff/g' \ | head -c -1 | gpg --import gpg: premature eof while reading rest of packet gpg: signal Segmentation fault caught ... exiting Segmentation fault That ugly horrible regex is: \xb9 : Find old-style public-subkey with 2 byte length .. : skip over the length bytes \x04 : looking for version 4 .... : skip over the timestamp \x01 : change the algorithm so it's not recognized by gcry_mpi_cmp. Then piping it into head to truncate the last packet. I think it should work on any RSA public key, e.g. just replace the --public-subkey taviso with the id, 4B092E28 works. Tavis. -- _o) $ lynx lock.cmpxchg8b.com /\\ _o) _o) $ finger taviso at sdf.org _\_V _( ) _( ) @taviso From wk at gnupg.org Fri Apr 22 20:33:24 2022 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Apr 2022 20:33:24 +0200 Subject: crash importing truncated subkeys In-Reply-To: (Tavis Ormandy via Gnupg-devel's message of "Thu, 21 Apr 2022 22:19:21 -0000 (UTC)") References: Message-ID: <87mtgd9de3.fsf@wheatstone.g10code.de> On Thu, 21 Apr 2022 22:19, Tavis Ormandy said: > Hello, I noticed that if there are two opaque identical public subkey > packets, but one is truncated, gpg crashes on import in gcry_mpi_cmp() Thanks. Tracked at https://dev.gnupg.org/T5940 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Fri Apr 22 20:40:30 2022 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Apr 2022 20:40:30 +0200 Subject: [PATCH gnupg] g10/import.c: ignore too large signature packets In-Reply-To: (Robert Bartel via Gnupg-devel's message of "Fri, 15 Apr 2022 18:47:27 +0200") References: Message-ID: <87ilr19d29.fsf@wheatstone.g10code.de> On Fri, 15 Apr 2022 18:47, Robert Bartel said: > A better behavior, instead of failing the public key import, would be to > just ignore too large signature packets. This can be achieved with the Right. However, this fixes just one case and has the side-effect that it can be used to strip for example an revocation signatures. This might be possible by uploading a signature with extra data the unhashed area. Depends on the keyserver. > I hope it does not introduce new problems in the code, like missing self > signatures when they are too large (will the import fail or lead to an Exactly. Broken keys are broken and should better not be used. > Please consider applying the patch upstream or making equivalent changes > to the code, to get GnuPG more DoS resistant in the future. I am not sure whether this makes a lot of sense given that this is just one way to trigger a limit in GnuPG. The limits have actually been implemented to limit the effect of broken keys. 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From r.bartel at gmx.net Sat Apr 23 11:43:53 2022 From: r.bartel at gmx.net (Robert Bartel) Date: Sat, 23 Apr 2022 11:43:53 +0200 Subject: [PATCH gnupg] g10/import.c: ignore too large signature packets In-Reply-To: <87ilr19d29.fsf@wheatstone.g10code.de> References: <87ilr19d29.fsf@wheatstone.g10code.de> Message-ID: On Fri, 2022-04-22 at 20:40:30 +0200, Werner Koch wrote: > On Fri, 15 Apr 2022 18:47, Robert Bartel said: > > > A better behavior, instead of failing the public key import, would be to > > just ignore too large signature packets. This can be achieved with the > > Right. However, this fixes just one case and has the side-effect that > it can be used to strip for example an revocation signatures. This > might be possible by uploading a signature with extra data the unhashed > area. Depends on the keyserver. Interesting. But this attack with a malicious signature packet already prevents the user from importing the key and seeing potential other valid revocation/third party signatures. When anyone can include subpackets in the unhashed area of any signature, then an attack would even be easier: just add a single subpacket with unknown type and the critical bit set. Then the evaluating software should consider the signature to be in error as per RFC 4880. Maybe the unhashed area should be completely ignored regardless its size to make the implementation more robust for public keyservers. > > I hope it does not introduce new problems in the code, like missing self > > signatures when they are too large (will the import fail or lead to an > > Exactly. Broken keys are broken and should better not be used. I don't consider the key in question broken. It just happens to have a single non conforming third party signature on it, which should not prevent the user from importing it including other valid signatures. > > Please consider applying the patch upstream or making equivalent changes > > to the code, to get GnuPG more DoS resistant in the future. > > I am not sure whether this makes a lot of sense given that this is just > one way to trigger a limit in GnuPG. The limits have actually been > implemented to limit the effect of broken keys. As I understand the RFC the maximum size of the hashed and unhashed areas is 64k bytes as for the 16 bit length fields. It doesn't seem to be much of a difference to support the maximum instead of only 10k today. But then again this could change when you have a lot of those large signatures added maliciously. This seems to be a general problem of the append only public keyserver architecture. Anyway, don't get me wrong, GnuPG already does a great job. But as always there might be room for improvement. I just don't like the idea of invalidating an arbitrary key on a keyserver for import by a single third party signature being so simple. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: not available URL: From r.bartel at gmx.net Sat Apr 23 18:02:12 2022 From: r.bartel at gmx.net (Robert Bartel) Date: Sat, 23 Apr 2022 18:02:12 +0200 Subject: crash importing truncated subkeys In-Reply-To: References: Message-ID: On Thu, 2022-04-21 at 22:19:21 -0000, Tavis Ormandy via Gnupg-devel wrote: > Hello, I noticed that if there are two opaque identical public subkey > packets, but one is truncated, gpg crashes on import in gcry_mpi_cmp() > > I just did this to repro: > > $ gpgcompose --public-key taviso --public-subkey taviso \ > --user-id anything --public-subkey taviso \ > | perl -p -e 's/(\xb9..\x04....)\x01/\1\xff/g' \ > | head -c -1 | gpg --import > gpg: premature eof while reading rest of packet > gpg: signal Segmentation fault caught ... exiting > Segmentation fault > > That ugly horrible regex is: > > \xb9 : Find old-style public-subkey with 2 byte length > .. : skip over the length bytes > \x04 : looking for version 4 > .... : skip over the timestamp > \x01 : change the algorithm so it's not recognized by gcry_mpi_cmp. > > Then piping it into head to truncate the last packet. > > I think it should work on any RSA public key, e.g. just replace > the --public-subkey taviso with the id, 4B092E28 works. Had time to reproduce this issue today with gpg 2.3.5 and valgrind: # off=528 ctb=b9 tag=14 hlen=3 plen=525 :public sub key packet: version 4, algo 255, created 1576527848, expires 0 unknown algorithm 255 gpg: can't handle public key algorithm 255 # off=1056 ctb=b4 tag=13 hlen=2 plen=32 :user ID packet: "Robert Bartel " # off=1090 ctb=b9 tag=14 hlen=3 plen=525 :public sub key packet: version 4, algo 255, created 1576527848, expires 0 unknown algorithm 255 gpg: premature eof while reading rest of packet gpg: pub rsa4096/0xABD4234D9E682972 2019-12-16 Robert Bartel ==3331== Invalid read of size 8 ==3331== at 0x484E9B5: bcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3331== by 0x42444D: cmp_public_keys (free-packet.c:514) ==3331== by 0x467952: collapse_subkeys (import.c:4137) ==3331== by 0x468149: import_one_real (import.c:1977) ==3331== by 0x46926F: import_one (import.c:2418) ==3331== by 0x469C67: import (import.c:673) ==3331== by 0x46A17A: import_keys_internal (import.c:569) ==3331== by 0x46A22D: import_keys (import.c:609) ==3331== by 0x412F32: main (gpg.c:4847) ==3331== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3331== One robustness fix would be to introduce NULL pointer checks in cmp_public_keys (free-packet.c:514), as the second subkey's opaque mpi value is introduced as NULL, because it was truncated. But the real fix seems to be adding error checks for read_rest() in g10/parse-packet.c:2584: when it returns NULL then set an error so the import fails because of an invalid packet and does not continue potentially using the NULL pointer later on. The same pattern should probably be applied to the similar calls of read_rest() in lines 2355 and 2897, just to be sure. Hope that helps a bit, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 25 20:53:51 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Apr 2022 20:53:51 +0200 Subject: [PATCH gnupg] g10/import.c: ignore too large signature packets In-Reply-To: (Robert Bartel via Gnupg-devel's message of "Sat, 23 Apr 2022 11:43:53 +0200") References: <87ilr19d29.fsf@wheatstone.g10code.de> Message-ID: <874k2h805c.fsf@wheatstone.g10code.de> On Sat, 23 Apr 2022 11:43, Robert Bartel said: > Anyway, don't get me wrong, GnuPG already does a great job. But as > always there might be room for improvement. I just don't like the idea > of invalidating an arbitrary key on a keyserver for import by a single > third party signature being so simple. For my key I had to resort to configs like this import-filter drop-sig= sig_created_d=2015-12-24 import-filter drop-sig=|| sig_created_d=2001-01-01 :-( 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Apr 25 21:03:45 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Apr 2022 21:03:45 +0200 Subject: [Announce] GnuPG 2.3.6 released Message-ID: <87zgk96l4e.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: version 2.3.6. This release fixes a regression introduced in 2.3.5 released just a few days ago. 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. Three different series of GnuPG are actively maintained: - Version 2.3 is the current stable version with a lot of new features compared to 2.2. This announcement is about the latest release of this series. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is only maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Noteworthy changes in version 2.3.6 =================================== * gpg: Fix regression in 2.3.5 importing longer keys. [T5941] * gpg: Emit an ERROR status as hint for a bad passphrase. [T5943] * gpg: Avoid NULL-ptr access due to corrupted packets. [T5940] * gpgsm: Improve the "Certificate not found" error message. [T5821] * agent: Pass pattern directly to gpg-check-pattern. [rGe529c54fe3] * scd: Fix hard-coded constant for RSA authentication key OpenPGP.3. [rG2848fe4c84] Release-info: https://dev.gnupg.org/T5937 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 FTP 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.3.6.tar.bz2 (7426k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.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.3.6_20220425.exe (4746k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.6_20220425.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A release of gpg4win including this version of GnuPG is scheduled for tomorrow. 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.3.6.tar.bz2 you would use this command: gpg --verify gnupg-2.3.6.tar.bz2.sig gnupg-2.3.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.3.6.tar.bz2, you run the command like this: sha1sum gnupg-2.3.6.tar.bz2 and check that the output matches the next line: 56706129203f422f4e5133ea76f5e72e05b0a404 gnupg-2.3.6.tar.bz2 26f937dc1a09e27426a45e51d7848954773edbbb gnupg-w32-2.3.6_20220425.tar.xz cf499dd9f6682d1b6bcc125b38b406e079be73ef gnupg-w32-2.3.6_20220425.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, 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/T5937 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. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. Fortunately, and this is still not common with free software, we have now 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 trademark 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 helping 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) 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. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce