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.
