lzip-bug
[Top][All Lists]
Advanced

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

Re: Docs still unclear on integrity


From: John Reiser
Subject: Re: Docs still unclear on integrity
Date: Mon, 13 Jun 2022 07:10:54 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0

On 6/13/22, 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.

If file.lz was generated by a single compression, then I believe
that decompression verifies integrity.  The test is simple:
the working value for the range coding must be zero.

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

If the input to decompression is the concatenation of the outputs
from two or more single compressions, and if lzip allows and interprets
this as representing a compression of the concatenation of the
original inputs, then detecting truncation at a point of concatenation
requires a check "has all the input been read?"  Such a test is
easy for a regular file, but problematic for a pipe such as stdin,
which can be specified on Linux using the filename "/proc/self/fd/0".

--




reply via email to

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