Vendor issues fixed (FreeBSD):
PR #778: ACL error handling
Issue #745: Symlink check prefix optimization is too aggressive
Issue #746: Hard links with data can evade sandboxing restrictions
This update fixes the vulnerability #3 and vulnerability #4 as reported in
the "non-cryptanalytic attacks against FreeBSD update components".
https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f
Vulnerability #2 has already been fixed in r304866
Vendor issues fixed:
PR #777: Multiple bugfixes for setup_acls()
This fixes a bug that caused ACLs not to be read properly for files and
directories inside subdirectories and as a result not being stored in tar
archives.
Vendor issues fixed:
Issue #731: Reject tar entries >= INT64_MAX
Issue #744 (part of Issue #743): Enforce sandbox with very long pathnames
Issue #748: Zip decompression failure with highly-compressed data
Issue #767: Buffer overflow printing a filename
Issue #770: Be more careful about extra_length
Vendor issues fixed:
Issue #744: Very long pathnames evade symlink checks
Issue #748: libarchive can compress, but cannot decompress zip some files
PR #750: ustar: fix out of bounds read on empty string ("") filename
PR #755: fix use of acl_get_flagset_np() on FreeBSD
Vendor issues fixed:
#686: Correctly grow buffer in archive_string_append_from_wcs_in_codepage()
FreeBSD PR #204157: Fix test on filesystems without birthtime support
PR: 204157
Fixed vendor issues:
Issue 553: Fix broken decryption for ZIP files
Issue 657: Allow up to 8k for the test root directory name
Issue 682: Correctly write gnutar filenames of exactly 512 bytes
Issue 708: tar should fail if a named input file is missing
PR 715: Fix libarchive/archive_read_support_format_mtree.c:1388:11:
error: array subscript is above array bounds
Fix a potential crash issue discovered by Alexander Cherepanov:
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.
Set a proper error message if we hit end-of-file when
trying to read a cpio header.
Suggested by Issue #395, although the actual problem there
seems to have been the same as Issue #394.
Add a check to archive_read_filter_consume to reject any
attempts to move the file pointer by a negative amount.
Note: Either this or commit 3865cf2 provides a fix for
Issue 394.
Issue 394: Segfault when reading malformed old-style cpio archives
Root cause here was an implicit cast that resulted in
reading very large file sizes as negative numbers.
Now all the gcc warnings I have reported upstream should be fixed.
Git branch: release
Git commit: 01580b4298a946fb31e822a083bf49e9f37809ac
Obtained from: https://github.com/libarchive/libarchive.git
