by libarchive but never caught on with other mtree implementations.
…ename Of interest: While working on this, I noted that we have an existing test for tar files with empty filenames. That test asserts that the correct behavior here is for the format handler to return the entry with the empty filename and a status of ARCHIVE_OK. Clients need to be robust against empty filenames.
The previous fix actually broke the fflag parsing. We cannot use strcmp() here because we're comparing a null-terminated string to a part of another string. This fix explicitly tracks the various string lengths and checks that they match before calling memcmp() or wmemcmp(). That avoids any buffer overrun without breaking the parser.
When parsing a directory name, we checked for the name length being zero, but not for the first byte being a null byte. Add a similar check for the file case.
While pruning trailing text from ar filenames, we did not check for an empty filename. This results in reading the byte before the filename on the stack. While here, change a number of ar format issues from WARN to FATAL. It's better to abort on a damaged file than risk reading garbage. No doubt, this will require additional tuning in the future.
The KwKwK case can never validly appear as the first token after a reset. Thanks to the afl-gcc folks for finding this.
Some of the pathname edits parse a part of the pathname in the entry, then try to set the pathname from that part. This leads the text routines to memcpy() from within the string buffer. Avoid this by simply using memmove() for low-level string append operations.
trying to read a cpio header. Suggested by Issue #395, although the actual problem there seems to have been the same as Issue #394.
I noticed that my skip callback was always being invoked with a request of 0. This is a bit wasteful since skip callbacks commonly involve a syscall like lseek(). Also, it seems good to error out when the skip callback is buggy, and claims to skip more than requested. Test Plan: ``` autoreconf -ivf && ./configure && make && make check ``` The same tests fail as before, with the same error messages. If interested, both failure logs are here: snarkmaster@00c9751 These are on Ubuntu 14.04.
attempts to move the file pointer by a negative amount. Note: Either this or commit 3865cf2 provides a fix for Issue 394.
Root cause here was an implicit cast that resulted in reading very large file sizes as negative numbers.
add the sample cpio_bin_le file to the test.
It seems bsdtar automatically handles stacked compression. This is a nice feature but it could be problematic when it's completely unlimited. Most clearly it's illustrated with quines: $ curl -sRO http://www.maximumcompression.com/selfgz.gz $ (ulimit -v 10000000 && bsdtar -tvf selfgz.gz) bsdtar: Error opening archive: Can't allocate data for gzip decompression Without ulimit, bsdtar will eat all available memory. This could also be a problem for other applications using libarchive.
This option suppresses both archiving and restoring xattrs. The latter relies on existing machinery; for the former, I've added a ARCHIVE_READDISK_NO_XATTR flag to archive_read_disk. Caveat: I've not implemented any tests for these new features.
Key problem: We were using archive_read_format_raw() to read the exclude file which does not accept empty files. Enabling archive_read_format_empty() and reworking the end-of-input handling fixed this. Also add a test for this case to prevent it from regressing.
…tory locator. This fixes a bug introduced in 94bab9f when I reworked the EOCD scan.
This was explored in pull request #78 by github user maksqwe. After considering the alternatives, I think the existing behavior was correct (but the comments were wrong and there was extraneous code). Extended tests to cover this case and some other cases that were not fully exercised.