My attempt to fix#2404 just made the confusion between the size of the
extracted file and the size of the contents in the tar archive worse
than it was before.
@ferivoz in #2557 showed that the confusion stemmed from a point where
we were setting the size in the entry (which is by definition the size
of the file on disk) when we read the `GNU.sparse.size` and
`GNU.sparse.realsize` attributes (which might represent the size on disk
or in the archive) and then using that to determine whether to read the
value in ustar header (which represents the size of the data in the
archive).
The confusion stems from three issues:
* The GNU.sparse.* fields mean different things depending on the version
of GNU tar used.
* The regular Pax `size` field overrides the value in the ustar header,
but the GNU sparse size fields don't always do so.
* The previous libarchive code tried to reconcile different size
information as we went along, which is problematic because the order in
which this information appears can vary.
This PR makes one big structural change: We now have separate storage
for every different size field we might encounter. We now just store
these values and record which one we saw. Then at the end, when we have
all the information available at once, we can use this data to determine
the size on disk and the size in the archive.
A few key facts about GNU sparse formats:
* GNU legacy sparse format: Stored all the relevant info in an extension
of the ustar header.
* GNU pax 0.0 format: Used `GNU.sparse.size` to store the size on disk
* GNU pax 0.1 format: Used `GNU.sparse.size` to store the size on disk
* GNU pax 1.0 format: Used `GNU.sparse.realsize` to store the size on
disk; repurposed `GNU.sparse.size` to store the size in the archive, but
omitted this in favor of the ustar size field when that could be used.
And of course, some key precedence information:
* Pax `size` field always overrides the ustar header size field.
* GNU sparse size fields override it ONLY when they represent the size
of the data in the archive.
Resolves#2548
(cherry picked from commit 29fd918e1886abacca88864ad3676fa237ff21e2)
Remove code for older versions of CMake.
CMake 3.14 stopped running on Windows XP and Vista.
Fix detection of wcscmo, wcscpy, wcslen
(cherry picked from commit 3a5a34b8211b68709090fcac71c45d9b5f59f4f2)
CMake 4.0 will be released soon and it refuses to accept a minimum
required version below 3.5 without additional flags.
(cherry picked from commit 4237b476fd4ef4b2b5ebac55811d92e73aeb5257)
Hello,
- The `CMAKE_COMPILER_IS_*` variables are deprecated and
`CMAKE_C_COMPILER_ID` can be used in this case instead.
- The legacy `endif()` command argument also simplified to avoid
repeating the condition.
(cherry picked from commit 2c2266432f1b0bf7be918f354140a6ba4a87a04c)
The lafe_errc function adds a newline by itself already, so do not
insert one into the message.
You can reproduce with the following commands:
```
touch archive.tar
bsdtar -xf archive.tar -C /non-existing
```
```
bsdtar --exclude ""
```
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
(cherry picked from commit a88e09a37069dd6a07d65f6dfee08a8563d79d8c)
Hi,
please find my approach to fix the CVE-2025-1632 and CVE-2025-25724
vulnerabilities in this pr.
As both error cases did trigger a NULL pointer deref (and triggered
hopefully everywhere a coredump), we can safely replace the actual
information by a predefined invalid string without breaking any
functionality.
---------
Signed-off-by: Peter Kaestle <peter@piie.net>
(cherry picked from commit c9bc934e7e91d302e0feca6e713ccc38d6d01532)
As remarked in #2521, this test has unreachable code on Windows, which
triggers a build failure in development due to warnings-as-errors.
(Release versions should not have warnings-as-errors.)
(cherry picked from commit 3512329ba9a06a7360601f195c5013c3161f5e70)
This also limits the amount of code where deprecation warnings are
suppressed.
Previously these warnings were only suppressed in the cmake build.
(cherry picked from commit 7708713b634eb2f72ffe484b565a5a87f58e8cb3)
The #if condition as-written fails for any major >= 3 if minor < 1, e.g.
GCC 15.0 (while in development).
Use the idiom described in the GCC docs [0] to avoid this.
[0] https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
Fixes: ab94a813b0f64cbc1bcb952bf55424a2d9c7f1d9
(cherry picked from commit a186d9662b4e3bc2e0f39d3248f9c1244c4346cb)
`Int32x32To64` macro internally truncates the arguments to int32, while
`time_t` is 64-bit on most/all modern platforms. Therefore, usage of
this macro creates a Year 2038 bug.
I detailed this issue a while ago in a writeup, and spotted the same
issue in this repository when updating the list of affected
repositories:
<https://cookieplmonster.github.io/2022/02/17/year-2038-problem/>
A few more notes:
1. I changed all uses of `Int32x32To64` en masse, even though at least
one of them was technically OK and used with int32 parameters only. IMO
better safe than sorry.
2. This is untested, but it's a small enough change that I hope the CI
success is a good enough indicator.
(cherry picked from commit 14b8803c40d36fe1f0c8b3bb2846d865e3adcfce)
Endianness is easy to determine at runtime, but detecting this a single
time and then reusing the cached result might require API changes.
However we can use compile-time detection for some known compiler macros
without API changes fairly easily. Let's start by enabling this for
Clang and GCC.
(cherry picked from commit 561b6430fd558af6e15b3cbe4258e0b30945b411)
This new test archive contains a C hello world executable built like so
on a ubuntu 24.04 machine:
```
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("hello, world\n");
return 0;
}
```
`powerpc-linux-gnu-gcc hw.c -o hw-powerpc -Wall`
The test archive that contains this executable was created like so,
using 7-Zip 24.08:
`7zz a -t7z -m0=deflate -mf=ppc
libarchive/test/test_read_format_7zip_deflate_powerpc.7z hw-powerpc`
This test fails in the first commit in this PR, and passes in the second
commit.
(cherry picked from commit 28cb5064d8dcd256237a736d7d6cbf7873de6671)
When the -s/regexp/replacement/ option was used with the b flag more
than once, the result of the previous substitution was appended to the
previous subject instead of replacing it. Fixed it by making sure the
subject is made the empty string before the call to realloc_strcat().
That in effect makes it more like a realloc_strcpy(), but creating a new
realloc_strcpy() function for that one usage doesn't feel worth it.
Resolves Issue libarchive/libarchive#2414
Co-authored-by: Stephane Chazelas <stephane@chazelas.org>
(cherry picked from commit 4d5106f2b5e48a34ec0e341974737252ed5aae84)
It looks like support for this library was removed in 2016, but we still
had some unused cmake code and a dead preprocessor block.
(cherry picked from commit 819a50a0436531276e388fc97eb0b1b61d2134a3)
Previously skipped tests were reported like this when running the *_test
binaries:
```
4: test_acl_platform_nfs4 ok (S)
```
Let's make this more obvious:
```
4: test_acl_platform_nfs4 skipped
```
(cherry picked from commit 7efa99bdb100cc5f32bb16324ef75920e49deaf4)
This plumbing is required for cmake/ctest to recognise and report
skipped tests.
Now skipped tests in cmake ci jobs are reported like so:
```
Start 7: libarchive_test_acl_platform_posix1e_read
7/785 Test #7: libarchive_test_acl_platform_posix1e_read ................................***Skipped 0.02 sec
```
And there is a list of skipped tests shown at the end of the test run.
(cherry picked from commit 8ac45a813e78fe6f2f8c40f0219f106a7ff9a28f)
This decreases the "Install library dependencies" step duration from
~4min to ~2min, and the "Build" step duration from ~10min to ~4min.
(cherry picked from commit ba76798136062868d2cbe80648ebc6fe2ebfbaed)
Prior to this change, the ci autoconf jobs weren't looking for homebrew
headers or libraries unless pkg-config was used, so for example the
"MacOS (autotools)" ci job wasn't testing lz4 or zstd code.
Relates to #2426.
(cherry picked from commit 29802f6a5e8543e61bac7d9dede42abf21ded5aa)
A few of libarchive's CI jobs don't find all the local support libraries
that they could be using. This change makes it easier to see which of
them are used.
(cherry picked from commit 0bbbe2883ef45b2027ea7395a691a855b1296cd1)
We currently use XZ Utils 5.6.3 on windows CI jobs, but the Windows
(msvc)
job which uses cmake seems to only be looking for the old library name,
liblzma.lib:
```
-- Looking for lzma_auto_decoder in C:/Program Files (x86)/xz/lib/liblzma.lib
-- Looking for lzma_auto_decoder in C:/Program Files (x86)/xz/lib/liblzma.lib - not found
-- Looking for lzma_easy_encoder in C:/Program Files (x86)/xz/lib/liblzma.lib
-- Looking for lzma_easy_encoder in C:/Program Files (x86)/xz/lib/liblzma.lib - not found
-- Looking for lzma_lzma_preset in C:/Program Files (x86)/xz/lib/liblzma.lib
-- Looking for lzma_lzma_preset in C:/Program Files (x86)/xz/lib/liblzma.lib - not found
-- Could NOT find LibLZMA (missing: LIBLZMA_HAS_AUTO_DECODER LIBLZMA_HAS_EASY_ENCODER LIBLZMA_HAS_LZMA_PRESET) (found version "5.6.3")
```
We need to update build/ci/github_actions/ci.cmd to look for lzma.lib
instead.
(cherry picked from commit 9b7540aaf1eddf558aa3f221b0c6c4ad5520dc9b)
This is mainly for non-cygwin newlib platforms that don't have tcgetattr
/ tcsetattr implemented
(cherry picked from commit 819c5b01a90e738ced6af237a6ae0d1aff981127)
