|From:||Timothy Beryl Grahek|
|Subject:||Re: [Lzip-bug] Tarlz 0.4: Use of 'ustar' format instead of 'posix'; question about future of Tarlz utility|
|Date:||Sun, 3 Jun 2018 10:01:25 -0700|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0|
Antonio Diaz Diaz wrote: [...] Please, could you verify that extended records are not protected by any checksum. Thanks.  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
|[Prev in Thread]||Current Thread||[Next in Thread]|