Use FILE_SHARE_WRITE and FILE_SHARE_DELETE when opening files on Windows
Many standard libraries(
[libc++](https://github.com/llvm/llvm-project/blob/main/libcxx/src/filesystem/posix_compat.h#L159),
[go](https://cs.opensource.google/go/go/+/refs/tags/go1.19.3:src/syscall/syscall_windows.go;l=331),
[rust](https://doc.rust-lang.org/src/std/os/windows/fs.rs.html#126-131)
) open files on windows with `FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE`
mode by default. Libarchive uses only `FILE_SHARE_READ`, so when file is
being opened by any program that uses these standard libraries
libarchive fails to open it. Here we change libarchive shared flags, so
it plays well with common practice in other programs.
Joris Clement [Fri, 28 Oct 2022 15:22:47 +0000 (17:22 +0200)]
Fix CMake warning
The warnings occurs at least with CMake version 3.24. It is caused by
CMake trying to find the gcc library due to case sensitivity.
The warning message was:
```
CMake Warning (dev) at /usr/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to `find_package_handle_standard_args` (LIBGCC)
does not match the name of the calling package (LibGCC). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
build/cmake/FindLibGCC.cmake:17 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:1269 (FIND_PACKAGE)
This warning is for project developers. Use -Wno-dev to suppress it.
```
Julien Voisin [Thu, 13 Oct 2022 12:13:19 +0000 (14:13 +0200)]
Extend the usage of the DONT_FAIL_ON_CRC_ERROR macro
DONT_FAIL_ON_CRC_ERROR is already used in the rar5 support code, so let's make
use of it in another places as well. This should tremendously help with
fuzzing.
Eric van Gyzen [Fri, 30 Sep 2022 15:28:09 +0000 (10:28 -0500)]
Support reading mtree files with tabs
Commit 45c5008c4 requires all characters in an mtree file to be
printable, as determined by `isprint()`. This broke support for
reading mtree files with tab characters, which are valid and otherwise
supported by libarchive. Allow them. Add a unit test.
John Reiser [Fri, 26 Aug 2022 16:51:19 +0000 (09:51 -0700)]
archive_entry_pathname() tries UTF-8 if MBS returns EILSEQ
For better pathname portability across OS, in particular Windows to Linux.
Original bug: unrar in https://bugzilla.redhat.com/show_bug.cgi?id=2120926
modified: libarchive/archive_entry.c
libarchive: Do not include sys/mount.h when linux/fs.h is present
These headers are in conflict and only one is needed by
archive_read_disk_posix.c therefore include linux/fs.h if it exists
otherwise include sys/mount.h
It also helps compiling with glibc 2.36
where sys/mount.h conflicts with linux/mount.h see [1]
Ben Wagner [Tue, 19 Jul 2022 17:02:40 +0000 (13:02 -0400)]
Validate entry_bytes_remaining in pax_attribute
The `size` attribute may contain a negative or too large value. Check
the range of the `entry_bytes_remaining` in `pax_attribute` the same way
as `header_common`. The test which is added passes both with and without
this change in a normal debug build. It is necessary to run with
`-fsanitize=undefined` to see that the undefined behavior is avoided.
Sergey Bobrenok [Sat, 25 Jun 2022 17:12:52 +0000 (20:12 +0300)]
rar5: Fix random initial offset if using archive_read_data_into_fd
archive_read_data_into_fd passes a pointer to an uninitialized
variable as an output 'offset' argument into archive_read_data_block
function, and expects that this variable will always be initialized
inside of it.
Like this:
size_t size;
int64_t offset;
archive_read_data_block(a, &buf, &size, &offset);
/* some work with offset here */
But rar5 implementation of archive_read_data_block function leaves the
'offset' argument uninitialized in one code path (if file is
compressed and there are no uncompressed pending data blocks).
As a result, archive_read_data_info_fd function is using an
uninitialized variable as an initial offset of an output file. And in
most cases it causes an appending sparse block of a random size at the
beginning of the output file.
David Macek [Sun, 17 Apr 2022 17:52:25 +0000 (19:52 +0200)]
archive_digest: Use correct providers with Windows Crypto
Trying to use SHA256, SHA384 or SHA512 with mtree when linked against
Windows Crypto would result in silent failure. The call to
`CryptCreateHash` would fail with 0x80090008. The docs[1] say that
these algorithms require a different crypto provider, so let's make
that a parameter for `win_crypto_init` and choose at the call site along
with the algorithm.
autotools: Fix static linking when openssl is enabled in windows
This adds Requires.private field in pkgconfig file. Using that field,
pkgconfig pulls all the private cflags or libs while static linking.
OpenSSL static libraries require some windows system libraies. Otherwise
static liking fails with libarchive.
This reverts commit 045e5c5a4460020e513516a5d1f3087094e67da3
For Windows platform, openssl 1.0.2 and earlier versions have
eay64 and eay32 libraries[1]. But from openssl 1.1.0 and above
versions have same library name[2] (libcrypto and libssl) like
other unix-like platforms.
projects / thirdparty / libarchive.git / log
