XZ embedded bug unpacking linux-3.8.tar.xz

[Antonio Diaz Diaz]

Denys Vlasenko wrote:
>>Why?. *.lzma are deprecated some time ago
> 
> Because someone submitted the code:

I also submitted the code[1]. :-)

[1] http://lists.busybox.net/pipermail/busybox/2012-December/078750.html


> In fact, it is surprisingly small:
> 
> archival/libarchive:
>    text    data     bss     dec     hex filename
>    2827       0       0    2827     b0b decompress_unlzma.o
>    7277       0       0    7277    1c6d decompress_unxz.o
>    2743       0       0    2743     ab7 decompress_bunzip2.o
>    5270       0       0    5270    1496 decompress_gunzip.o

Just the same size as lunzip minus the header and integrity checkings:

text+data text+rodata    rwdata       bss filename
      2928        2928         0         0 
archival/libarchive/decompress_lunzip.o


> So basically, lzip lost the race wrt adoption. xz is used more widely.
> Kernel tarballs are .xz, not .lz.

It depends on where you get your kernels from:

http://linux-libre.fsfla.org/pub/linux-libre/releases/3.8-gnu/

BTW, xz files are a bit smaller than lz files in the above directory, 
but you need twice the memory to decompress them. Of course lzip can 
achieve the same (or better) compresion if you add "-s 64MiB" to the 
command line.


> What I'm saying is that bbox project would like to have is (ideally)
> _one_ LZMA decoder. Unpacking the compressed stream from two formats
> isn't a terribly difficult thing.

But xz is not (only) a LZMA encoder, therefore no LZMA decoder will ever 
be able to decode xz streams.


> But can lzip decompress unxz *stream*?

If we have learned something from this thread is that not even all 
unxz's can decompress all xz streams. Much less verify their integrity.


Regards,
Antonio.