summaryrefslogtreecommitdiff
path: root/Makefile.am
Commit message (Collapse)AuthorAgeFilesLines
* tar/test/test_option_ignore_zeros.c: test tar --ignore-zerosRyan Libby2021-11-191-0/+1
| | | | Add some basic tests for operations on concatenated archives.
* Merge pull request #1598 from JiaT75/zip_entry_size_unset_store_fix_1547Martin Matuška2021-11-161-0/+1
|\ | | | | Zip entry size unset now honors user requested compression level
| * Adding test to Makefile.amjiat752021-10-191-0/+1
| |
* | Added test case for ustar directory handlingSamanta Navarro2021-09-051-0/+2
|/ | | | Based on test_compat_tar_hardlink.c and with input by Tim Kientzle.
* Do not follow symlinks when processing the fixup listMartin Matuska2021-08-221-0/+1
| | | | | | | Use lchmod() instead of chmod() and tell the remaining functions that the real file to be modified is a symbolic link. Fixes #1566
* Merge pull request #1530 from owtaylor/close-short-writesMartin Matuška2021-05-271-0/+1
|\ | | | | On close, handle short writes from archive_write_callback
| * On close, handle short writes from archive_write_callbackOwen W. Taylor2021-05-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The archive_write_callback passed to archive_write_open() is documented as: "each call to the write callback function should translate to a single write(2) system call. On success, the write callback should return the number of bytes actually written" And in most places, the code repeatedly calls the write callback, but when flushing the buffer at close, the write callback was called once, assuming it would write everything. This could result in a truncated archive. A test is added to test short writes in different code paths.
* | Merge pull request #1509 from mariXanna/fix/#1508Martin Matuška2021-05-271-0/+1
|\ \ | |/ |/| Added support of deflate algorithm in symbolic link decompression for zip archives
| * Added support of deflate algorithm in symbolic link decompression for zip ↵Masalskaya, Anna2021-03-161-0/+1
| | | | | | | | archives
* | add support for reading and writing PWB and V7 cpio archivesTom Ivar Helbekkmo2021-03-051-0/+1
| |
* | rearrange cpio output format selectionTom Ivar Helbekkmo2021-03-051-0/+1
|/
* fix test failureMasalskaya, Anna2020-09-301-0/+1
|
* move test to another placeMasalskaya, Anna2020-09-221-1/+0
|
* unit test addedMasalskaya, Anna2020-09-221-0/+1
|
* Introduce archive_read_support_filter_by_code()Martin Matuska2020-06-091-0/+1
| | | | Fixes #1258
* Add test for #1357 (detection of pzstd compressed files)Martin Matuska2020-04-301-0/+1
|
* tar reader: update handling of RHT.security.selinux xattrMartin Matuska2020-04-301-2/+4
| | | | | Add test for PR #1348 Rename test_read_pax_schily_xattr to test_read_pax_xattr_schily
* Add testcase for ZIPX files with LZMA_STREAM_END markerMartin Matuska2020-02-131-0/+1
| | | | Testcase for issue #1257 (PR #1297)
* 7z reader: support Delta filter with values 2-256Martin Matuska2020-02-061-0/+2
| | | | Fixes #987
* RAR5 reader: reject files that declare invalid header flagsGrzegorz Antoniak2020-02-021-0/+1
| | | | | | | | | | | | | | | One of the fields in RAR5's base block structure is the size of the header. Some invalid files declare a 0 header size setting, which can confuse the unpacker. Minimum header size for RAR5 base blocks is 7 bytes (4 bytes for CRC, and 3 bytes for the rest), so block size of 0 bytes should be rejected at header parsing stage. The fix adds an error condition if header size of 0 bytes is detected. In this case, the unpacker will not attempt to unpack the file, as the header is corrupted. The commit also adds OSSFuzz #20459 sample to test further regressions in this area.
* Unify unsupported entry file type error message in writerMartin Matuska2020-01-251-0/+1
| | | | Closes #1320
* Add test_option_safe_writes to tar testsMartin Matuska2020-01-201-0/+1
|
* Add test for reading 7z archives with Digests in PackInfoMartin Matuska2019-12-211-0/+2
| | | | Fixes #1295
* RAR5 reader: verify window size for multivolume archivesGrzegorz Antoniak2019-12-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | RAR5 archives can contain files that span across multiple .rar files. If the archive contains a big file that doesn't fit to first .rar file, then this file is continued in another .rar file. In this case, the RAR compressor first emits the FILE base block for this big file in the first .rar file. Then, it finishes first .rar file, and creates the new .rar file. In this new file, it emits the continuation FILE block that marks start of the continuation data for the rest of the huge file. The problem was that the RAR5 reader didn't ignore the window size declaration when parsing through the continuation FILE base block. The malicious file could declare a different window size inside the continuation base block than was declared in the primary FILE base block in the previous volume. The window size from continuation block was applied, but the actual window buffer was not reallocated. This resulted in a potential SIGSEGV error, since bounary checks for accessing the window buffer were working incorrectly (the window size variable didn't match the actual window buffer size). The commit fixes the issue by ignoring the window size declaration in the continuation FILE base block when switching volumes. The commit also contains a test case and OSSFuzz sample #19509.
* Add the "xattrhdr" option to pax write options.Martin Matuska2019-12-111-0/+4
| | | | | | | This allows us to control whether "SCHILY.xattr", "LIBARCHIVE.xattr" or both headers (default) are written when storing extended attributes. Document "hdrcharset" option for pax.
* Add missing testfile to Makefile.amMartin Matuska2019-11-171-0/+1
|
* Added a test case on lha with UTF-16 filenames.Claybird2019-11-061-0/+1
|
* RAR5 reader: verify window size for solid filesGrzegorz Antoniak2019-09-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | RAR5 archives can contain files compressed independently of each other, and files that share a common window buffer, so files which are compressed using 'solid' method. In the latter case, all files are required to use the same window buffer, so window size should also be the same. OSSFuzz sample #15482 declares a different window size for multiple solid files. RAR5 reader doesn't reallocate window buffer when decompressing solid files, so it was possible to perform an out-of-bounds read by declaring two solid files, where the second solid file declared the window size parameter that was bigger than window size used in first solid file. This commit introduces additional checks to ensure all solid files are using the same window size. The commit also adds a test case using OSSFuzz sample #15482 to hunt down regressions in the future. Some other test cases had to be adjusted as well, because other OSSFuzz samples were also declaring different window sizes for solid files. So this commit has changed the error reporting for those invalid sample files.
* RAR5 reader: fix ARM filter going beyond window buffer boundaryGrzegorz Antoniak2019-06-241-0/+1
| | | | | | | | | | | | | | | | | RAR5 uses filters in order to mutate data just before compression, to achieve a better compression ratio. After decompression, this mutation needs to be reversed by processing various filters that the compressor uses. One of such filters is an ARM executable file filter, which changes some bytes in the input stream if the stream is recognized as an executable file with ARM native code. This commit fixes the situation when the decompressor using an ARM filter was referencing a byte outside current window buffer. Such action is invalid and can produce segmentation faults. This commit also adds a test using OSSFuzz sample #15431.
* Add test_read_format_rar5_different_window_size.rar.uu to Makefile.amMartin Matuska2019-06-171-0/+1
|
* RAR reader: extend fix user after freeMartin Matuska2019-06-151-0/+1
| | | | | | | | If read_data_compressed() returns ARCHIVE_FAILED, the caller is allowed to continue with next archive headers. In addition to rar->start_new_table=1 we need to set rar->ppmd_valid=0. Reported by: OSS-Fuzz issue 15120
* Merge pull request #1109 from kientzle/Issue1055Martin Matuška2019-05-181-0/+2
|\ | | | | Issue #1055: Ignore padding in Zip extra field data
| * Merge branch 'master' into Issue1055Tim Kientzle2019-05-041-2/+39
| |\
| * | Issue #1055: Ignore padding in Zip extra field dataTim Kientzle2018-12-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PKWare's APPNOTE.TXT simply documents the extra field as a concatenation of <header><data> objects. It does not explicitly allow nor prohibit additional padding. Libarchive originally treated any extraneous data in the extra field as an indication of corruption and issued an error. However, some Zip writers do appear to include additional zero bytes in the extra field and expect them to be ignored. This works if: * We consider a field type of 0000 to be a padding field. * In particular, 0000 0000 is then a valid field with type zero and zero bytes of data. * If there are fewer than 4 bytes left at the end of the extra data (too few to be a valid extra field object), ignore it. With the above conventions, zero padding can occur anywhere in the extra field as long as the padding occurs in a multiple of four bytes. Any number of bytes can occur at the end: groups of four bytes will be skipped as valid empty fields; any final group of less than four bytes will be simply ignored. The test exercises all of the above options; the extra field data for the file in this archive has: * Four zero bytes at the beginning * A valid UX field * A pad field of type zero with a non-zero length * An additional three final bytes By verifying that the UX data was read correctly and that there were no errors, we can be confident that all of the padding here was handled correctly.
* | | tar reader: treat empty archives with a GNU volume header as validMartin Matuska2019-05-181-0/+2
| | | | | | | | | | | | Fixes #1062
* | | Add test_read_format_rar_ppmd_use_after_free.rar.uu to Makefile.amMartin Matuska2019-05-121-0/+1
| | | | | | | | | | | | Entry was missing in PR #1199
* | | Add missing distcheck files to Makefile.amMartin Matuska2019-05-111-0/+12
| | |
* | | add new raw test file to the distributionMike Frysinger2019-05-111-0/+1
| | |
* | | zip: add support for Info-ZIP Unicode Path Extra FieldTomasz Mikolajewski2019-04-261-0/+2
| |/ |/| | | | | | | The zip specification supports storing path names in UTF-8 encoding via the Info-ZIP Unicode Path Extra Field (0x7075).
* | RAR5 reader: add support for symlinks, hardlinks, owner and group dataMartin Matuska2019-04-181-0/+33
| | | | | | | | Add missing test archives to Makefile.am
* | Windows symlinks: new functions and extended tar headerMartin Matuska2019-04-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New functions: archive_entry_symlink_type() archive_entry_set_symlink_type() Suppoted value constants: AE_SYMLINK_TYPE_UNDEFINED AE_SYMLINK_TYPE_FILE AE_SYMLINK_TYPE_DIRECTORY New extended tar header: LIBARCHIVE.symlinktype The function archive_entry_symlink_type() retrieves and the function archive_entry_set_symlink_type() sets the symbolic link type of an archive entry. The information about the symbolic link type is required to properly restore symbolic links on Microsoft Windows. If the symlink type is set to AE_SYMLINK_TYPE_FILE or AE_SYMLINK_TYPE_DIRECTORY and a tar archive is written, an extended tar header LIBARCHIVE.symlinktype is stored with the value "file" or "dir". When reading symbolic links on Windows, the link type is automatically stored in the archive_entry structure. On unix systems, the symlink type has no effect when reading or writing symbolic links.
* | tar: add option --exclude-vcsMartin Matuska2019-04-141-0/+1
| | | | | | | | Fixes #999
* | Fix 'make dist' to include blake2 headersPavel Raiskup2019-03-081-0/+2
| | | | | | | | Fixes #1157
* | Remove test_compat_pax_libarchive_2xMartin Matuska2019-01-301-2/+0
| | | | | | | | | | | | The is determined for FreeBSD only and it doesn't work since 2015. There is no significant need to keep this functionality, it may be deprecated.
* | Added missing files into Makefile.amGrzegorz Antoniak2018-12-181-0/+2
|/
* archive_read_support_format_rar5: enable blake2 support via libb2Martin Matuska2018-10-061-2/+6
|
* Add missing RAR5 files to Makefile.amMartin Matuska2018-10-051-0/+4
|
* alphabetical orderArshan Khanifar2018-02-071-1/+1
|
* Test case for using -C in conjunction with an @mtree format fileArshan Khanifar2018-02-061-0/+1
|
* zip: Allow backslash as path separatorJohn Starks2017-11-151-0/+1
| | | | | | | | | | Some Windows zip archivers, such as PowerShell's Compress-Archive, use backslash as the path separator in violation of the zip specification. Info-Zip works around this by supporting this for archives that report "version made by" of 0 (MS-DOS). This change adds the same workaround to libarchive and adds a test of this case using a zip file created with PowerShell.
View Lorry Controller Status