[Top][All Lists]

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

Re: Docs still unclear on integrity

From: Antonio Diaz Diaz
Subject: Re: Docs still unclear on integrity
Date: Tue, 14 Jun 2022 16:23:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

Hi Askar,

Askar Safin wrote:
Hi. I installed lzip 1.23-3 to my debian from debian repo. Is it true
that default decompression mode (i. e. lzip -d file.lz) verifies
archive? "man lzip" doesn't say anything about this.

Thanks for reporting this. I have just extended the description of '-d, --decompress' in the man page to
  "decompress, test compressed file integrity"
and have made a similar change to the info manual.

Also, is it true that compressed file truncation is absolutely always
detected? (Multiply bit flips are hard to detect with absolute
guarantee, but I think it is quite possible to always detect file
truncation.) Is file truncation detected in default mode (lzip -d
file.lz)? "man lzip" is silent on this

File truncation is always detected if it happens inside a member, but it can't be detected if it happens just after the end of a member. This is a well-known limitation[1] of any tool that allows file concatenation (gzip, bzip2, lzip, and even tar):

$ echo foo | lzip > foo.lz
$ echo bar | lzip > bar.lz
$ tar -c foo.lz bar.lz | dd bs=512 count=4 2>/dev/null | tar -t ; echo $?

If you want to be sure that file truncation is always detected, you may either use single-member files, or append some trailing data[2] to the file and then verify it at the receiving side. For example you may append the size of the whole concatenated file and verify it against the compressed size shown by --list:

$ lziprecover --strip=tdata foo.lz bar.lz > foobar.lz
$ wc -c < foobar.lz >> foobar.lz
$ lzip --verbose --list foobar.lz
   dict   memb  trail   uncompressed     compressed   saved  name
   4 KiB     2      3              8             80 -900.00%  foobar.lz
$ lziprecover --dump=tdata foobar.lz

Best regards,

[1] http://www.nongnu.org/lzip/manual/lziprecover_manual.html#Unzcrash
If the decompressor returns with zero status, unzcrash compares the output of the decompressor for the original and corrupt files. If the outputs differ, it means that the decompressor returned a false negative; it failed to recognize the corruption and produced garbage output. The only exception is when a multimember file is truncated just after the last byte of a member, producing a shorter but valid compressed file.

[2] http://www.nongnu.org/lzip/manual/lziprecover_manual.html#Trailing-data

reply via email to

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