[Top][All Lists]

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

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

From: Pádraig Brady
Subject: Re: Please, use --check=crc32 or switch to a safe format
Date: Sun, 2 Apr 2017 20:56:31 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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.


reply via email to

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