[gnutls-help] Switching to gzip for tarballs (was gnutls 3.8.12)

[Antonio Diaz Diaz]

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.