From antonio at gnu.org Tue May 5 20:19:53 2026 From: antonio at gnu.org (Antonio Diaz Diaz) Date: Tue, 05 May 2026 20:19:53 +0200 Subject: [gnutls-help] Switching to gzip for tarballs (was gnutls 3.8.12) In-Reply-To: <87seb70yvp.fsf@josefsson.org> References: <698CA6D1.5090503@gnu.org> <87seb70yvp.fsf@josefsson.org> Message-ID: <69FA34C9.4050002@gnu.org> Simon Josefsson wrote: > I find the arguments to chose anything beyond gzip are rather weak > today. I changed GNU InetUtils to gzip recently (from xz+gz). Fair enough. I'm fine with gzip. > Changing compression algorithm has a cost too. I'm not convinced the > arguments for any particular compression method are strong enough to > warrant switching. Maybe they aren't, but I'm not arguing for a particular compression method. I'm warning about the safety risks of using xz. Some recently fixed bugs in gnutls and linux may help illustrate the problem. A week ago, a couple bug fixes about unchecked lengths listed in the announcement of gnutls-3.8.13 reminded me that the xz format has many length fields whose correctness can't be checked [1]. A couple days later I received a warning about a serious vulnerability in linux named 'Copy Fail', which seems to have been caused by a useless optimization [2]. The fix consisted in getting rid of all the complexity added for in-place operation and just copy the AD (Associated Data) directly. This reminded me that the xz format is full of troublesome useless features [3] whose inconvenients could have been avoided just by not including useless features in the format. It is a well-known fact that the xz format is unsafe. The catch is that xz is unsafe by design, and therefore undetected corruption is considered the user's problem, not a bug. Even the documentation of xz-utils warns about it. For example, from xz-5.8.3: INSTALL (line 307): liblzma and the command line tools can decompress files which use unsupported integrity check type, but naturally the file integrity cannot be verified in that case. doc/man/txt/xz.txt (line 1478): Outside embedded systems, all .xz format decompressors support all the check types, or at least are able to decompress the file without verifying the integrity check if the particular check is not supported. src/liblzma/common/block_decoder.c (line 262): // Initialize the check. It's caller's problem if the Check ID is not // supported, and the Block decoder cannot verify the Check field. Like AF_ALG [4], xz is a massive, largely pointless attack surface which has been causing problems, including several CVEs, ever since it was released in 2009. There's no need to use such a complex and poorly designed container format as xz just to compress a tarball. Linux and crypto libraries are the basis of our security. If they make unsafe decisions like implementing useless features/optimizations, or using the xz format, then IMHO there is something wrong in their decision-making process that needs to be revised. As the risks associated to the use of xz can be easily avoided by switching to any of the 3 safe and time-proven formats previously used by gnutls to compress its tarballs (gzip, bzip2, and lzip), I respectfully suggest the gnutls maintainrs to use one of them to compress the tarballs instead of xz. (For example bzip2, which seems to be the format used by most of the libraries in gnupg.org). [1] http://www.nongnu.org/lzip/xz_inadequate.html#unprot_len [2] https://www.openwall.com/lists/oss-security/2026/04/29/23 [3] http://www.nongnu.org/lzip/xz_inadequate.html#misguided [4] https://www.openwall.com/lists/oss-security/2026/04/30/15 Best regards, Antonio.