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

[Antonio Diaz Diaz]

Pádraig Brady wrote:
> Yes I mentioned previously in the thread that the download
> was protected by the cryptographic signature.
> This issue is only adding protection "during uncompression".

Even if busybox users were willing to verify the signature every time 
they decompress the file to compensate for the lack of integrity 
checking, it would not solve the problem. Checking the compressed file 
(i.e. checking the data before decompressing it) is not enough because 
the probability of undetected decompression errors is not negligible. 
Decompressing is not a trivial task, and it is the integrity of the 
decompressed data what matters.

Not verifying the decompressed data can be a serious safety breach. The 
undetected corruption can be minimal (a bit flip changing a '1' into a 
'5'), making perhaps possible for the code to compile and produce a 
wrong executable.

The gzip manual warns against using formats that do not provide 
consistency checks:

"The standard compress format was not designed to allow consistency 
checks. However gunzip is sometimes able to detect a bad .Z file. If you 
get an error when uncompressing a .Z file, do not assume that the .Z 
file is correct simply because the standard uncompress does not 
complain. This generally means that the standard uncompress does not 
check its input, and happily generates garbage output."

Julian Seward documented in the man page of bzip2 the need to verify the 
integrity of the decompressed data:

"As a self-check for your protection, bzip2 uses 32-bit CRCs to make 
sure that the decompressed version of a file is identical to the 
original.  This guards against corruption of the compressed data, and 
against undetected bugs in bzip2".

Think that the devices running busybox are probably more prone to both 
software errors and hardware glitches than a desktop computer.

Moreover, adding support for CRC64 to busybox goes against busybox's 
goal of minimizing code size:

http://busybox.net/about.html
"BusyBox combines tiny versions of many common UNIX utilities into a 
single small executable. [...] BusyBox has been written with 
size-optimization and limited resources in mind."

IMO distributing coreutils also in another format is the perfect 
solution. It allows busybox users verify the integrity of the data, 
makes easy for pristine-tar to reproduce the tarball, and is better for 
long-term archiving. I can't find a single drawback in adding a second 
tarball to the distribution.


Best regards,
Antonio.