Re: [PATCH] maint: RFC: add lzip tarballs

[Antonio Diaz Diaz]

Hello Assaf,

Assaf Gordon wrote:
> I do have some concerns about the lzip program:
>
> It is written in C++. Not a problem by itself, but seems a bit at odds as a 
> requirement for system-level package like coreutils.

I maintain 3 lzip (de)compressors written in C:
http://www.nongnu.org/lzip/clzip.html
http://www.nongnu.org/lzip/lunzip.html
http://www.nongnu.org/lzip/pdlzip.html

But there are more, including a version of 7-Zip with lzip decompression 
support built in:
http://github.com/mcmilk/7-Zip-zstd


> I'm not sure how portable and well-tested the program is on the large number of 
> platforms that coreutils aim to cater to.

Lzip itself is pretty portable. The C versions are even more portable 
(clzip has been compiled wit gcc 2.7.2 IIRC). Lunzip provides a "low 
memory" mode able to decompress any file using as little memory as 50 
kB, irrespective of the dictionary size used to compress the file. It 
has been tested on a laptop with a 486 processor and 4 MiB of RAM.

About how well-tested lzip is, you can see 
http://www.nongnu.org/lzip/manual/lzip_manual.html#Quality-assurance


> I think the test suite is a bit lacking, especially compared to all the claims 
> about recovery and robustness of the lzip format.

The test suite run by 'make check' is just a minuscule subset of the 
full tests. As you can read in the link above:
"Three related but independent compressor implementations, lzip, clzip 
and minilzip/lzlib, are developed concurrently. Every stable release of 
any of them is subjected to a hundred hours of intensive testing to 
verify that it produces identical output to the other two".

and

"Additionally, the three implementations have been extensively tested 
with unzcrash, valgrind and 'american fuzzy lop' without finding a 
single vulnerability or false negative".


Best regards,
Antonio.