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
--
Bob Friesenhahn
bfriesen@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
