[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why I am happy to dump gzip for xz

From: Bob Friesenhahn
Subject: Re: Why I am happy to dump gzip for xz
Date: Tue, 6 Mar 2012 09:06:47 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Tue, 6 Mar 2012, Jim Meyering wrote:

Personally, I fail to see a similar compelling case for xz.  It's a much

If you were more intimately familiar with gzip's code,
you would have switched long ago ;-)

There is plenty of "bad code" in production use.  Much of it is GPLed.

Why I am happy to dump gzip for xz:
 - xz compresses much better
 - xz decompresses more quickly
 - xz's format is well-designed and extensible
 - xz's code base is robust and well-implemented (yes, I've audited it)
 - gzip's code is a mess, and has even had recent CVEs and data-loss bugs,
     which means we are doing users a favor by encouraging them to stop
     using their vulnerable/defective gzip programs.
     As gzip maintainer, I can attest that the code is far from ideal,
     both on a robustness scale and on the maintainability front.

I have not heard any arguments against creating xz tarballs. The arguments so far are against eliminating the gz tarballs for at least the next couple of years.

The vulnerability issue is a red-herring since it seems unlikely that the Autoconf project will strive to create Autoconf distribution files which exploit gzip weaknesses. Also, people who don't use the gzip format are not exposed to any risk associated with gzip. If Autoconf distribution files can be modified after the fact to add a gzip expliot, then hope is already lost since the Autoconf source code may well have been modified as well.

There are likely plenty of security issues hiding in 'xz' because it has quite a lot of source code and there has been less time to find and build the exploits. The 'xz' software is written in C language (and apparently assembly code) and therefore inherits all of the security weaknesses which are inherent in C. C is fundamentally an "insecure" language which requires special measures to assure secure code.

The question remains why the GCC project is not using the 'xz' format. The GCC project produces huge tarballs which might benefit from 'xz' but they choose not to use it.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]