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.
Brad King [Wed, 16 Feb 2022 12:31:56 +0000 (07:31 -0500)]
windows: include archive_platform.h first in blake2s sources
Move the inclusion added by commit 90978db1 (windows: make sure we use
the right calling convention for libc, 2021-10-13, v3.6.0~39^2~1) to be
first. This is our convention in all other `.c` sources. It ensures
that our configured `_WIN32_WINNT` value is defined before including any
system headers.
RAR5 reader: add more checks for invalid extraction parameters
Some specially crafted files declare invalid extraction parameters that
can confuse the RAR5 reader.
One of the arguments is the declared window size parameter that the
archive file can declare for each file stored in the archive. Some
crafted files declare window size equal to 0, which is clearly wrong.
This commit adds additional safety checks decreasing the tolerance of
the RAR5 format.
RAR5 reader: fix invalid memory access in some files
RAR5 reader uses several variables to manage the window buffer during
extraction: the buffer itself (`window_buf`), the current size of the
window buffer (`window_size`), and a helper variable (`window_mask`)
that is used to constrain read and write offsets to the window buffer.
Some specially crafted files can force the unpacker to update the
`window_mask` variable to a value that is out of sync with current
buffer size. If the `window_mask` will be bigger than the actual buffer
size, then an invalid access operation can happen (SIGSEGV).
This commit ensures that if the `window_size` and `window_mask` will be
changed, the window buffer will be reallocated to the proper size, so no
invalid memory operation should be possible.
This commit contains a test file from OSSFuzz #30442.
Tim Kientzle [Wed, 2 Feb 2022 03:33:41 +0000 (19:33 -0800)]
Reorganize test code a bit
A few guiding principles:
* Each test source file includes ONLY "test.h" to make it easy
to create new tests.
* Each test suite has a "test.h" that includes "test_util/test_common.h"
to get access to all the common testing utility functions.
So "test_common.h" is then responsible for including
any smaller headers that declare specific pieces of
shared test functionality.
I've also pulled some test filtering logic that was _only_ used
in test_main.c into that file, and repurposed "test_utils.[ch]"
for common utility code. (Eventually, a lot of the assertion
helpers currently in "test_main.c" should probably be organized
into one or more source files of their own.)
Alex Richardson [Thu, 17 Sep 2020 17:28:17 +0000 (18:28 +0100)]
Avoid millions of rand() calls() when running tests
Many tests use a loop calling rand() to fill buffers with test data. As
these calls cannot be inlined, this adds up to noticeable overhead:
For example, running on QEMU RISC-V the test_write_format_7zip_large_copy
test took ~22 seconds before and with this change it's ~17 seconds.
This change uses a simpler xorshift64 random number generator that can be
inlined into the loop filling the data buffer. By default the seed for this
RNG is rand(), but it can be overwritten by setting the TEST_RANDOM_SEED
environment variable.
For a native build the difference is much less noticeable, but it's still
measurable: test_write_format_7zip_large_copy takes 314.9 ms ± 3.9 ms
before and 227.8 ms ± 5.8 ms after (i.e. 38% faster for that test).
Petr Malat [Thu, 23 Dec 2021 10:47:04 +0000 (11:47 +0100)]
Support libzstd compiled with compressor disabled
ZSTD library can be compiled with the compressor disabled, which is
handy on space restricted systems as the compressor accounts for more
than two thirds of the library size.
Detect this case and use libzstd for the decompression only.
Compression will be done using zstd binary if it's available.
Peter Pentchev [Wed, 22 Dec 2021 15:05:53 +0000 (17:05 +0200)]
Raise the lzip max dictionary size to 512MB.
The lzip documentation specifies that the logarithm of the dictionary
base size may be in the range 12-29, and the lzip utility is quite
capable of creating an archive with a dictionary larger than 128M if
passed the appropriate -s command-line option.
Graham Percival [Wed, 22 Dec 2021 02:00:19 +0000 (18:00 -0800)]
Fix Y2038 check
If time_t is a signed 32-bit integer, then we cannot represent times
after 03:14:07 on 2038-01-19. Indicating an error if (Year > 2038) is
not sufficient; for safety, we need to bail if (Year >= 2038).
As the comment above this line notes, it would be better to check if
time_t is 32 bits first. And even if we didn't check for that, we could
use a much more complicated check:
Walter Lozano [Sat, 18 Dec 2021 01:44:09 +0000 (22:44 -0300)]
Fix check for tape device
In b6b423f0 a fallback in tar to stdio was implemented. However, the check
for the tape device didn't interpret the correct value returned from
access(). Fix the check to implement the fallback to stdio properly.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
projects / thirdparty / libarchive.git / log
