Re: Please, use --check=crc32 or switch to a safe format

[Matias Fonzo]

On Sun, 2 Apr 2017 20:56:31 -0700
Pádraig Brady <address@hidden> wrote:

> On 02/04/17 08:51, Matias Fonzo wrote:
> > Hello Pádraig,
> > 
> > On Mon, 27 Mar 2017 20:28:35 -0700
> > Pádraig Brady <address@hidden> wrote:
> >   
> >> On 27/03/17 19:55, Michael Stone wrote:  
> >>> On Mon, Mar 27, 2017 at 11:47:10PM +0100, Ariel Santana Naranjo
> >>> wrote:    
> >>>> If changing xz's options can't fix the problem, would you re-add
> >>>> a second format?  Until coreutils-8.13 the tarball was
> >>>> distributed in two formats.  I think adding a second format
> >>>> would fix the problem for busybox and for pristine-tar because
> >>>> xz seems to be the only format affected by these problems!    
> >>>
> >>> What, exactly, is the problem?    
> >>
> >> busybox's unxz can't detect bit errors during uncompression
> >> due to not supporting the default crc64 checksum generated by xz.
> >> It could if you generate the tarball with xz --check=crc32.
> >> Though I don't think it's practical to adjust all projects
> >> to pass this option to xz; rather adding crc64 support to
> >> unxz seems like the best approach.
> >>
> >> Note if you're extracting the tarball then you're not on a
> >> deeply embedded device without a compiler etc. so it would
> >> be surprising that xz would not be available.  
> > 
> > Err, busybox supplies xz...  
> 
> Sure. But my point was if you're compiling on this system,
> a crc64 capable xz shouldn't be too hard to obtain.
>
> >> Even in that extreme edge case, you could use an intermediate
> >> system to extract and checksum the data.  
> > 
> > What if this intermediate system is not available?.  
> 
> See point above.
> Anyway the general point of this thread is that
> fixing this with options to each generator of xz is not practical.
> Either the default xz crc should be changed to crc32,
> or more likely busybox xz would gain crc64 support.

All of what you propose are patches to palliate part of the symptoms of
the bad design of xz.  And in addition -- to be implemented by others.
The use of a format that does not have these problems is not mentioned
here!

pgpxi019VFEds.pgp
Description: OpenPGP digital signature