Re: [Lzip-bug] Tarlz 0.4: Use of 'ustar' format instead of 'posix'; question about future of Tarlz utility

[Timothy Beryl Grahek]

Hi Antonio,

> Antonio Diaz Diaz wrote: [...] Please, could you verify[1] that 
> extended records are not protected by any checksum. Thanks.
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html 

Yes, it does appear that the 'pax' Entended Header does not contain a 
checksum. By examining the 'ustar' header and the 'pax' extended header, 
it is clear that one of the main differences between them is that the 
'pax' extended header does not contain a checksum. That is alarming. In 
fact, it is made even more alarming by the following fact:

"[Typeflag] g [r]epresents global extended header records for the 
following files in the archive. [...] The typeflag g global headers 
should not be used with interchange media that could suffer partial data 
loss in transporting the archive." So it looks like it is highly 
recommended that reliable interchange media is used in the event that 
typeflag g is used. My best guess is that typeflag g will only be used 
if typeflag x can't be used; of course, typeflag x cannot be used if 
'ustar' requirements can't be satisfied.

All of this is quite concerning. Is there not another tar format that 
doesn't suffer from these problems that doesn't have the limitations of 
the 'ustar' format? What about the GNU format? Perhaps that format has 
the same problem as this 'pax' extended format? It is tempting for me to 
avoid all tar formats except for 'ustar' considering I am now no longer 
sure that other tar formats besides 'ustar' keep track of data integrity.

All in all, I suppose it is unambiguous that the extended records in 
'pax' cannot be used if we are concerned about preventing a fragmented 
format from becoming commonplace. In other words, the tar 'pax' format 
must be changed or abandoned in favor of a better tar format that 
provides a checksum for extended records.

> Juan Francisco Cantero Hurtado wrote: [...] Anyway, IIUC, the tar 
> headers are inside of the lzip member which checks the integrity of 
> the content. The risk of corrupted headers is low.
This sounds good, except that by adopting a tar format, someone may be 
interested in using Lzip to decompress the tar file without 
simultaneously extracting the contents; if someone actually does this, 
which is extremely likely, this will negate the data protection provided 
by Lzip.

Best regards,

Timothy