Emil Velikov [Sat, 14 Mar 2020 13:31:31 +0000 (13:31 +0000)]
Remove #ifdef chain in __archive_digest init
Follow the approach set by the crypto and use the exact same name for
the respective functions. This is perfectly fine, since only one
provider can be used (built) at given time.
As a result, we can kill off the excessively long ifdef chain, making
the more more manageable and shorter.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
David Capello [Sat, 18 Apr 2020 18:09:43 +0000 (15:09 -0300)]
Use /w1nnnn instead of /wennnn to enable warnings on MSVC Debug mode
On MSVC /wennnn treats the specific warning number nnnn as an error:
https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level
But we want to enable this only when ENABLE_WERROR is defined (so the
general /WX flag is enough to treat all warnings as errors instead of
using /we).
Martin Matuska [Mon, 2 Mar 2020 07:55:44 +0000 (08:55 +0100)]
Safe writes: improve error handling
Print message if creation of temporary file fails.
When rename of temporary file fails, exit with ARCHIVE_FAILED.
Reword message on failed rename.
Revert d84ec3f and 85b9f66, call archive_set_error()w before unlinking.
Ward Vandewege [Fri, 14 Feb 2020 02:56:09 +0000 (21:56 -0500)]
New ASCII format: fix hard link description
The description of how hard links are handled in the 'new ASCII format' is wrong. Cpio stores the *first*, not *last* copy of the file with its entire contents, followed by entries with filesize set to zero for each subsequent entry that is hard linked. While creating the archive, how would it ever know it was processing the last one!
Brad King [Thu, 6 Feb 2020 19:28:02 +0000 (14:28 -0500)]
Fix possible heap-buffer-overflow in archive_string_append_from_wcs on Windows
Fix `archive_string_append_from_wcs_in_codepage` to account for the
already-used portion of the buffer when computing the size of the
remaining buffer for `WideCharToMultiByte` output.
RAR5 reader: reject files that declare invalid header flags
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.
Martin Matuska [Thu, 30 Jan 2020 23:30:34 +0000 (00:30 +0100)]
Update filter and format options in manual pages.
The list of format and filter options in bsdtar(1) is incomplete.
Add reference to manual pages archive_write_set_options(3) and
archive_read_set_options(3) for a complete list of supported options.
Brad King [Thu, 30 Jan 2020 14:49:22 +0000 (09:49 -0500)]
libarchive: Fix detection of 'major' on Solaris 11.4
In `archive_pack_dev.c` there is code checking the `HAVE_MAJOR` macro,
but it is not computed. Port the equivalent logic from
`archive_entry.c` to define the macro.
Martin Matuska [Mon, 20 Jan 2020 10:41:18 +0000 (11:41 +0100)]
Implement ARCHIVE_EXTRACT_SAFE_WRITES on Windows
As Windows does not support atomic rename/_wrename
we have to unlink the file right before calling _wrename
leaving a short unsafe window where a different file with the
same name can be created and make the rename operation fail.
zoulasc [Mon, 20 Jan 2020 12:20:42 +0000 (13:20 +0100)]
Introduce archive_write_disk(3) flag ARCHIVE_EXTRACT_SAFE_WRITES
This flag changes the way that regular files are extracted:
Instead of removing existing files first and re-creating them in
order to replace their contents, a temporary file is created and
when writing to the temporary file is completed, the file is
rename(2)d to the final destination name.
This has the effect of presenting a consistent view of the file to
the system (either the file with the new contents or the file with
the old contents). Removing and overwriting the file has the
undesired side effect that the the system can either not see the
file at all (from the time it is being removed till the time it is
being re-created), or worse it can see partial file contents. This
is problematic when extracting system files (for example shared
libraries).
If the existing file that is going to be overwritten is a hard link,
for now we unlink it before calling rename(2). This can be done
correctly by creating a hardlink to a tmpnam(3) generated file
and then use rename(2), but that is fairly intrusive and requires
refactoring.
archive_read_support_format_rar.c:
Fix invalid nested loop break.
Comment out dead code sections.
Simplify size comparsions of lensymbol and offsymbol.