Spelling fixes (#2412)

Check for tcgetattr / tcsetattr before using it for readpassphrase implementation (#2424)

This is mainly for non-cygwin newlib platforms that don't have tcgetattr
/ tcsetattr implemented

Add missing definition for getline polyfill (#2425)

The fallback for when `getline` is not implemented in libc was not
compiling due to the fact that the definition for it was missing, so add
the definition.

bsdtar.1: Mention rar support + manual page polish (#2423)

I have been using this for years without realizing it decompresses rar.

+ add rar to supported decompression formats
+ use section references to link sections (this makes them clickable in
GUIs)
+ add paragraph breaks for consistent spacing
+ pdtar is not this program, so use Sy per mdoc style guide
+ do almost the same in reverse for bsdtar
+ remove parenthetical around a complete sentance

Thank you so much, this is wonderful software.

Test with XZ Utils 5.6.3 on windows CI jobs (#2417)

This change fixes the autotools build to work with xz-utils 5.6.3, which
changed library names on windows, and fixes a couple of tests that I
noticed had dependencies on liblzma.

nit(tar): fix typo (#2420)

Moving the tests' integer reading functions to test_utils. (#2410)

Moving the tests' integer reading functions to test_utils so that they
all use the same as well as moving the few using the archive_endian
functions over to the test_utils helper.

Follow-up from libarchive#2390.

Ignore ustar size when pax size is present (#2405)

When the pax `size` field is present, we should ignore the size value in
the ustar header. In particular, this fixes reading pax archives created
by GNU tar with entries larger than 8GB.

Note: This doesn't impact reading pax archives created by libarchive
because libarchive uses tar extensions to store an accurate large size
field in the ustar header. GNU tar instead strictly follows ustar in
this case, which prevents it from storing accurate sizes in the ustar
header.

Resolves #2404

7zip reader: add SPARC filter support for non-LZMA compressors (#2399)

These two new test archives contain 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;
}
```

`sparc64-linux-gnu-gcc hw.c -o hw-sparc64 -Wall`

The two test archives that contain this executable were created like so,
using the https://github.com/tehmul/p7zip-zstd fork of 7-Zip:
`7z a -t7z -m0=zstd -mf=SPARC
libarchive/test/test_read_format_7zip_zstd_sparc.7z hw-sparc64`
`7z a -t7z -m0=lzma2 -mf=SPARC
libarchive/test/test_read_format_7zip_lzma2_sparc.7z hw-sparc64`

Two test files are required, because the 7zip reader code has two
different paths, one for lzma and one for all other compressors.

The test_read_format_7zip_lzma2_sparc test is expected to pass, because
LZMA BCJ filters are implemented in liblzma.

The test_read_format_7zip_zstd_sparc test is expected to fail in the
first commit, because libarchive does not currently implement the SPARC
BCJ filter. The second commit will make test_read_format_7zip_zstd_sparc
pass.

Revert "Use proper Create OS value on Windows to fix archive charset detection (#2240) (#2401)

Two problems are prompting this revert:

* In order to change the Create OS value to "Windows", we would need to
record other data (such as `external_attributes`) in Windows format as
well.

* Changing the Create OS value doesn't actually fix the
filename-encoding issue that originally motivated this PR

This reverts commit 755af84301adc4262722a4c88671a8d0a1c83fae.

Rename bsdtar test_extract_tar_absolute_paths source file for consistency (#2400)

The `-P` flag is uppercase, so the test file should be named
test_option_P_upper.c for consistency with the other test files in this
directory.

Sorry about the noise.

tests: redirect stdout in one call in test_extract_tar_absolute_paths (#2386)

This redirects the message "Removing leading '/' from member names"
from stderr to a file in one case.

Fix tests added in #2284 (#2387)

Revert "add `--mac-metadata` test for `--format zip` - see #2041 (#2045)"

This reverts commit ea56096020e2c6c764052adfab63e11fd745f9de.

add `--mac-metadata` test for `--format zip` - see #2041 (#2045)

Submitting this test at the request of @kientzle on issue #2041.

Note that failure is currently expected, as the feature it tests is not
yet implemented!

write_xar: move libxml2 behind an abstraction layer (#1849)

This commit prepares the XAR writer for another XML writing backend.

Almost everything in this changeset leaves the code identical to how
it started, except for a new layer of indirection between the xar writer
and the XML writer.

The things that are not one-to-one renames include:
- The removal of `UTF8Toisolat1` for the purposes of validating UTF-8
- The writer code made a copy of every filename for the purposes of
  checking whether it was Latin-1 stored as UTF-8. In xar, Non-Latin-1
  gets stored Base64-encoded.
- I've replaced this use because (1) it was inefficient and (2)
  `UTF8Toisolat1` is a `libxml2` export.
- The new function has slightly different results than the one it is
  replacing for invalid UTF-8. Namely, it treats illegal UTF-8 "overlong"
  encodings of Latin-1 codepoints as _invalid_. It operates on the principle
  that we can determine whether something is Latin-1 based entirely on how
  long the sequence is expected to be.
- The move of `SetIndent` to before `StartDocument`, which the
  abstraction layer immediately undoes. This is to accommodate XML writers
  that require indent to be set _before_ the document starts.

7zip writer: initial support for zstandard compression (#2137)

This is intended to be compatible with:
* https://github.com/mcmilk/7-Zip-zstd
* https://github.com/tehmul/p7zip-zstd

Adding XZ, LZMA, ZSTD and BZIP2 support to ZIP writer (#2284)

PPMD may come later but I'd rather first iron out style issues with the
ones needing only to wire up libraries already-used in Libarchive before
going at the ones possibly requiring implementing algorithms as well.

Closes #1046 and resolves #1179.

Use proper Create OS value on Windows to fix archive charset detection (#2240)

See https://sourceforge.net/p/sevenzip/bugs/2463

Reintroduce size_t cast to clarify the use of a u32 shift on a u64 arg (#2383)

Regressed in #2285

Various small fixes for Cygwin, Haiku, OpenIndiana (#2346)

Cygwin 3.5.4 (same applies for 3.5.3),
I get a compile error as shown below after a simple ./configure and
make. Adding <windef.h> solves the problem.

Co-authored-by: vco <god@universe.sys>

tests: use const char instead of char in one case (#2381)

Found in test_extract_cpio_absolute_paths.c when compiling FreeBSD base

Ignore checksum mismatches when fuzzing tar archives (#2378)

This should speed up fuzzing just a bit, so we
can find more bugs!

CI: Bump the all-actions group across 1 directory with 4 updates (#2379)

Bumps the all-actions group with 4 updates:

actions/checkout from 4.1.6 to 4.2.1
actions/upload-artifact from 4.3.3 to 4.4.3
github/codeql-action from 3.25.6 to 3.26.12
ossf/scorecard-action from 2.3.3 to 2.4.0

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Increase the hole size for this test to 32MiB (#2380)

APFS on macOS 15 seems to have a higher threshold for creating sparse
files.

Convert the tools and respective tests to SPDX (#2317)

This is the first part of converting the project to use SPDX license
identifiers instead using the verbose license text.

The patches are semi-automated and I've went through manually to ensure
no license changes were made. That said, I would welcome another pair of
eyes, since I am only human.

See https://github.com/libarchive/libarchive/issues/2298

---------

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

Update archive_private to avoid template keyword (#2342)

People really should never, ever, ever use libarchive internal headers.  And they definitely should not expect libarchive internal headers to work in a C++ compiler.  (C++ and C are really just not that compatible.)

However, people do a lot of things they shouldn't:  Avoid the reserved C++ keyword `template`

configure.ac,CMakeLists.txt: Add libbsd on Haiku for readpassphrase (#2352)

Followup from #2346

Add libbsd to make/cmake configuration for linking readpassphrase on
Haiku.
Maybe there is a better way to do this for cmake, I'm not that familiar
with it.

Co-authored-by: vco <god@universe.sys>

CI: Update build environments (#2373)

FreeBSD 13.3 -> 13.4
FreeBSD 14.0 -> 14.1
Ubuntu 22.04 -> 24.04

Fix two leaks in tar header parsing (#2377)

OSS-Fuzz found two places where an error return would bypass cleaning up
a local allocation.

Credit: OSS-Fuzz

tests: change file format from dos to unix in one test file (#2376)

[7zip] Read/write symlink paths as UTF-8 (#2252)

I previously tried to find documentation on how symlinks are expected to
be stored in 7zip files, however the best reference I could find was
[here](https://py7zr.readthedocs.io/en/latest/archive_format.html). That
site suggests that symlink paths are stored as UTF-8 encoded strings:

Update RAR5 code to report encryption (#2096)

Currently, the RAR5 code always reports
`ARCHIVE_READ_FORMAT_ENCRYPTION_UNSUPPORTED` for
`archive_read_has_encrypted_entries`, nor does it set any of the
entry-specific properties, even though it has enough information to
properly report this information. Accurate reporting of encryption is
super useful for applications because reporting an error message such as
"the archive is encrypted, but we don't currently support encryption" is
a lot better than a not generally useful `errno` value and a
non-localizable error string with a confusing and unpredictable error
message.

Fixes #1661

Change to Windows absolute symlinks. (#2362)

Change to read absolute symlinks as verbatim paths instead of NT paths:
as far as I can see, libarchive can deal with verbatim paths while it
can't with NT ones.

Fixes #2274.

configure.ac: remove incorrect 4th argument to `AC_CHECK_FUNCS` (#2334)

Remove the incorrect 4th argument from `AC_CHECK_FUNCS` calls. The macro
uses only three arguments, so it was ignored anyway. Furthermore, in at
least once instance it was wrong -- due to a typo in `attr/xatr.h`
header name.

Don't crash on truncated tar archives (#2364)

The tar header parsing overhaul in #2127 introduced a systematic
mishandling of truncated files: the code incorrectly checks for whether
a given read operation failed, and ends up dereferencing a NULL pointer
in this case. I've gone back and double-checked how
`__archive_read_ahead` actually works (it returns NULL precisely when it
was unable to satisfy the read request) and reworked the error handling
for each call to this function in archive_read_support_format_tar.c

Resolves #2353
Resolves https://issues.oss-fuzz.com/issues/42537231

Sanity-check gzip header field length (#2366)

OSS-Fuzz managed to construct a small gzip input that decompresses into
another gzip input with an extremely large filename field. This causes
libarchive to hang processing the inner gzip.

Address this by rejecting any gzip input where the filename or comment
fields exceed 1MiB.

Credit: OSS-Fuzz

Clarify crc32 variable names (#2367)

No functional change, just a tiny style improvement.

Use `crc32_computed` to refer to the crc32 that the reader has computed
and `crc32_read` to refer to the value that we read from the archive.
That hopefully makes this code a tiny bit easier to follow. (It confused
me recently when I was double-checking something in this area, so I
thought an improvement here might help others.)

Fix error message printing (#2368)

We always print the error message with or without -v, but for some
reason, we were omitting the path being processed. Simplify so that we
always print the full error including context.

Don't use Windows bcrypt when building for Windows XP or older (#2374)

The header may be detected but we can't use the calls.

The same check is already done in many places but not all of them.

bsdcpio should exit with an error code if an entry can't be extracted (#2371)

For example if --insecure is not specified, and one of the security
checks fails.

Add absolute path test for bsdtar (#2370)

Check that extracting archive entries with absolute paths uses mangled
relative paths unless -P / --absolute-paths is specified.

Simplify tests added in #2363, use testworkdir (#2369)

Fix pathname overwrite in header_old_tar() (#2360)

Fixes #2359

Miscellaneous code cleanup (#2285)

This fixes various code quality issues I encountered while chasing a
memory leak reported by test automation. I failed to reproduce the
memory leak, but I hope you find this useful nonetheless.

Fix ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS on windows (#2363)

Reenable CI tests for MSVC (#2356)

These were disabled when migrating from Cirrus CI. Let's enable them for
github workflows, disable any failing tests on this configuration and
leave TODO notes to fix them.

This was the only failure that I found:
```
  684/764 Test #684: bsdtar_test_option_ignore_zeros_mode_c ...................................***Failed    0.10 sec

  If tests fail or crash, details will be in:
     C:\Users\RUNNER~1\AppData\Local\Temp/bsdtar_test.exe.2024-09-29T11.42.13-000

  Reference files will be read from: D:/a/libarchive/libarchive/tar/test
  Running tests on: "D:\a\libarchive\libarchive\build_ci\cmake\bin\Release\bsdtar.exe"
  Exercising: bsdtar 3.8.0 - libarchive 3.8.0dev zlib/1.3 liblzma/5.4.4 bz2lib/1.1.0 libzstd/1.5.5

   39: test_option_ignore_zeros_mode_c
  D:\a\libarchive\libarchive\tar\test\test_option_ignore_zeros.c(99): File should be empty: test-c.err
      File size: 112
      Contents:
  0000 62 73 64 74 61 72 2e 65 78 65 3a 20 61 3a 20 43 bsdtar.exe: a: C
  0010 61 6e 27 74 20 74 72 61 6e 73 6c 61 74 65 20 75 an't translate u
  0020 6e 61 6d 65 20 27 28 6e 75 6c 6c 29 27 20 74 6f name '(null)' to
  0030 20 55 54 46 2d 38 0d 0a 62 73 64 74 61 72 2e 65  UTF-8..bsdtar.e
  0040 78 65 3a 20 62 3a 20 43 61 6e 27 74 20 74 72 61 xe: b: Can't tra
  0050 6e 73 6c 61 74 65 20 75 6e 61 6d 65 20 27 28 6e nslate uname '(n
  0060 75 6c 6c 29 27 20 74 6f 20 55 54 46 2d 38 0d 0a ull)' to UTF-8..

  Totals:
    Tests run:                1
    Tests failed:             1
    Assertions checked:      21
    Assertions failed:        1
    Skips reported:           0
```

Remove two unnecessary strings from the tar state (#2345)

`pax_global` is not used at all and can be removed.

`longname` is only used locally within one function, so convert it to a
local variable there.

Clean up linkpath between entries (#2343)

PR #2127 failed to clean up the linkpath storage between entries. As a
result, after the first hard/symlink entry in a pax format archive, all
subsequent entries would get the same link information.

I'm really unsure how this bug failed to trip CI. I'll do some digging
in the test suite before I merge this.

Resolves #2331 , #2337

P.S. Thanks to Brad King for noting that the linkpath wasn't being
managed correctly, which was a big hint for me.

tar/write.h: Support `sys/xattr.h` (#2335)

Synchronize the last use of `attr/xattr.h` to support using
`sys/xattr.h` instead. The former header is deprecated on GNU/Linux, and
this replacement makes it possible to build libarchive without the
`attr` package.

tar: fix memory leaks when processing symlinks or parsing pax headers (#2338)

Fix memory leaks introduced by #2127:

* `struct tar` member `entry_linkpath` was moved at the same time as
   other members were removed, but its cleanup was accidentally removed
   with the others.

* `header_pax_extension` local variable `attr_name` was not cleaned up.

Resolves #2336

Be more cautious about parsing ISO-9660 timestamps (#2330)

Some ISO images don't have valid timestamps for the root directory
entry. Parsing such timestamps can generate nonsensical results, which
in one case showed up as an unexpected overflow on a 32-bit system.

Add some validation logic that can check whether a 7-byte or 17-byte
timestamp is reasonable-looking, and use this to ignore invalid
timestamps in various locations. This also requires us to be a little
more careful about tracking which timestamps are actually known.

Resolves issue #2329

Libarchive 3.8.0dev

Release 3.7.5

cmake: do not require zlib (#2327)

Followup to #2318 which accidentally made zlib required.

Tested locally by increasing the version in CMakeLists.txt to 1.4.1
(which does not exist yet), and confirming that the build reports that a
suitable version of zlib was not found, while the build continued..

Fix SOVERSION computation logic in CMake to match libtool's (#1976)

Fix SOVERSION computation logic in CMake to match libtool's

Closes #1857

Co-authored-by: isuruf <isuruf@users.noreply.github.com>
Co-authored-by: Timothy Lyanguzov <theta682@gmail.com>

archive_write: validate header before arguments (#2315)

Fixes: 575e2eab ("Fix handling a negative bytes_per_block values
(#2206)")

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

Fix Windows path when writing zip entries (#2309)

Before writing a zip entry, its' pathname might be modified for two
reasons:

1. Path using Windows path separators will be converted to POSIX style.
2. Path using local encoding will be transcoded if a target charset is
set.

Must make sure these two mechanisms can coexist without overwriting each
other.

cmake: look for zlib >= 1.2.1 (#2318)

zlib 1.2.0 added this improvement for inflate:
"Raw inflate no longer needs an extra dummy byte at end"

libarchive does not feed zlib extra data beyond end of stream, so it
does not work with zlib < 1.2.0.

Fix ar archive entries having no type (#2290)

Also removes some whitespace damage.

Closes #2241

tests: reduce zstd long option to 23 (#2305)

With 26 and 27, the sub-test is pushing 2G and 4G memory respectively.

There is no particular reason why we need to push for higher limits
here, so let's pick 23 with weights around 0.25G. The test suite overall
is in the 0.25 - 0.5G range and this fits perfectly.

Closes: https://github.com/libarchive/libarchive/issues/2080
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

zip: Fix test failure (#2304)

Fix `test_write_format_zip_stream` failure when `HAVE_ZLIB_H` is not
defined.

If `libz` is present, `zip` archives would be compressed by default,
which requires `zip_version=20`. Otherwise, the archive is not
compressed and only requires `zip_version=10`. I'm building libarchive
on a machine not intended for developing, so basicly there's no optional
dependencies like `libz` available, guess that's why nobody else has
reported this issue.

Prefer a != b over !(a == b) (#2303)

This is not C++ or another language where this may have been necessary,
nor is the condition complex at all; it is only a single equality
comparison.

cat: squash s/it/is/ typo (#2292)

Closes: https://github.com/libarchive/libarchive/issues/2128
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

windows reader: set tree::current for initial tree walking (#2212)

Fixes #2211

Fix compilation warnings (#2246)

Fix warnings I'm hitting, at least with MSVC

Fix CVE-2024-26256 (#2269)

Opening a manipulated RAR archive could lead to remote code execution

Security: CVE-2024-26256
Co-authored-by: Timothy Lyanguzov <theta682@gmail.com>

b64encode: Fix typo in error message (#2281)

If this function fails, log b64encode instead of uu.

Pax parsing should consistently use the FIRST pathname/linkname (#2264)

Pax introduced new headers that appear _before_ the legacy
headers.  So pax archives require earlier properties to
override later ones.

Originally, libarchive handled this by storing the early
headers in memory so that it could do the actual parsing
from back to front.  With this scheme, properties from
early headers were parsed last and simply overwrote
properties from later headers.

PR #2127 reduced memory usage by parsing headers in the
order they appear in the file, which requires later headers
to avoid overwriting already-set properties.  Apparently,
when I made this change, I did not fully consider how charset
translations get handled on Windows, so failed to consistently
recognize when the path or linkname properties were in fact
actually set.  As a result, the legacy path/link values (which have
no charset information) overwrote the pax path/link values (which
are known to be UTF-8), leading to the behavior observed in
#2248.  This PR corrects this bug by adding additional
tests to see if the wide character path or linkname properties
are set.

Related:  This bug was exposed by a new test added in #2228
which does a write/read validation to ensure round-trip filename
handling. This was modified in #2248 to avoid tickling the bug above.
I've reverted the change from #2248 since it's no longer necessary.
I have also added some additional validation to this test to
help ensure that the intermediate archive actually is a pax
format that includes the expected path and linkname properties
in the expected places.

Fix 'test_pax_filename_encoding_UTF16_win' by explicitly setting hdrcharset (#2248)

It would seem as though #2127 conflicted with my change #2228.

I previously thought that the writer was putting info into the archive
that strings were encoded in UTF-8, but I'm not so sure of that
anymore... In any case, explicitly setting `hdrcharset` on the reader as
well is a reasonable alternative and something we do already.

RAR5 reader: clear 'data ready' cache on window buffer reallocs (#2265)

The RAR5 reader is using a small stack of cached pointers to submit the
rendered data to the caller. In malformed files it's possible for this
pointer cache to be desynchronized with the memory buffer those pointers
are pointing to, making libarchive crash on invalid memory access.

OSS-Fuzz Issue: 70024

Quickly reject tar entries > 2^60 bytes w/o risking overflow (#2263)

In particular, this ensures that we cannot overflow rounding-up
calculations. Recent tar changes put in a lot of sanity limits on the
sizes of particular kinds of data, but the usual behavior in most cases
was to skip over-large values. The skipping behavior required
rounding-up and accumulating values that could potentially overflow
64-bit integers. This adds some coarser checks that fail more directly
when an entry claims to be more than 1 exbibyte (2^60 bytes), avoiding
any possibility of numeric overflow along these paths.

OSS-Fuzz Issue: 70062

Free some strings in the tar reader (#2262)

Fix a few cases where strings were initialized (with a heap allocation)
but never properly cleaned up.

OSS-Fuzz Issue: 70056

Try to fix some CI config issues on macOS (#2261)

macOS CI is reporting some warnings about unavailable versions of some
utilities. I'll take a stab at fixing those...

Fix a minor date-parsing bug and fill in missing ISO9660 testing (#2260)

This is somewhat academic, since we don't actually expose any of the
ISO9660 header information that is stored in 17-byte date format, but
inspection revealed an off-by-one error in the parsing here.

This also proved a nice motivation to fill in some verification in our
most basic ISO9660 test case.

archive_entry_perms.3: clarify that you don't need to strdup() [gu]name (#2239)

Currently updating archivemount which does
```c
pwd = getpwuid(st.st_uid);
if(pwd)
archive_entry_set_uname(node->entry, strdup(pwd->pw_name));
grp = getgrgid(st.st_gid);
if(grp)
archive_entry_set_gname(node->entry, strdup(grp->gr_name));
```
and I'm assuming the strdups are actually leaks? The manual is silent on
this.

Fix max path-length metadata writing (#2243)

Previous code added `.XXXXXX` to the end of the filename to write the
mac metadata. This is a problem if the filename is at or near the
filesystem max path length. This reuses the same code used by
create_tempdatafork to ensure that the filename is not too long.

Ignore out-of-range gid/uid/size/ino and harden AFIO parsing (#2258)

The fuzzer constructed an AFIO (CPIO variant) archive that had a
rediculously large ino value, which caused an overflow of a signed
64-bit intermediate.

There are really three issues here:
* The CPIO parser was using a signed int64 as an intermediate type for
parsing numbers in all cases. I've addressed the overflow here by using
a uint64_t in the parser core, but left the resulting values as int64_t.
* The AFIO header parsing had no guards against rediculously large
values; it now rejects an archive when the ino or size fields (which are
allowed to be up to 16 hex digits long) overflow int64_t to produce a
negative value.
* The archive_entry would accept negative values for gid/uid/size/ino.
I've altered those so that these fields treat any negative value as zero
for these fields.

There was one test that actually verified that we could read a field
with size = -1. I've updated that to verify that the resulting size is
zero instead.

OSS-Fuzz Issue: 70019

Don't try to read rediculously long names (#2259)

The Rar5 reader would read the name size, then read the name, then check
whether the name size was beyond the maximum size allowed. This can
result in a very large memory allocation to read a name. Instead, check
the name size before trying to read the name in order to avoid excessive
allocation.

OSS-Fuzz Issue: 70017

tar: free two temporary allocated strings after use (#2255)

OSS-Fuzz issue: 70020

Fix multiple vulnerabilities identified by SAST (#2256)

I went through ~50 findings of SAST reports and identified a few of them
as true positives. I might still have missed some intended uses or some
magic in the code so please provide feedback if you think some of these
shouldn't be applied and why.

I explained the changes in the separate comments.

Checks for null references (#2251)

Microsoft's static analysis tool found some vulnerabilities from
unguarded null references that I changed in
[microsoft/cmake](https://github.com/microsoft/cmake). Pushing these
changes upstream so they can be added to
[kitware/cmake](https://github.com/Kitware/CMake).

Fix gnutar creation with unicode hardlink names on Windows (#2227)

The code currently uses `archive_entry_hardlink` to determine if an
entry is a hardlink, however on Windows, this call will fail if the path
cannot be represented in the current locale. This instead checks to see
if any entry in the `archive_mstring` is set.

Fix & optimize string conversion functions for Windows (#2226)

All three parts of this change effectively stem from the same
assumption: most of the code in `archive_string.c` assumes that MBS <->
UTF-8 string conversion can be done directly and efficiently. This is
not quite true on Windows, where conversion looks more like MBS <-> WCS
<-> UTF-8. This results in a few inefficiencies currently present in the
code.

First, if the caller is asking for either the MBS or UTF-8 string, but
it's not currently set on the `archive_mstring`, then on Windows, it's
more efficient to first check if the WCS is set and do the conversion
with that. Otherwise, we'll end up doing a wasteful intermediate step of
converting either the MBS or UTF-8 string to WCS, which we already have.

Second, in the `archive_mstring_update_utf8` function, it's more
efficient on Windows to first convert to WCS and use that result to
convert to MBS, as opposed to the fallback I introduced in a previous
change, which converts UTF-8 to MBS first and disposes of the
intermediate WCS, only to re-calculate it.

Fix usage of GetVolumePathNameW in UWP before 20H1 (#2247)

It started being allowed in UWP in 20H1.

Fix issue when skipping first file in 7zip archive that is a multiple of 65536 bytes (#2245)

We noticed an issue where we had an archive that, if you skipped the
first entry and tried to extract the second, you'd get a failure saying
`Truncated 7-Zip file body`. Turns out that this is because the first
file in the archive is a multiple of 65,536 bytes (the size of the
uncompressed buffer) and therefore after `read_stream` skipped all of
the first file, `uncompressed_buffer_bytes_remaining` was set to zero
(because all data was consumed) and then it calls
`get_uncompressed_data` with `minimum` set to zero. This then saw that
`minimum > zip->uncompressed_buffer_bytes_remaining` evaluated to false,
causing us to read zero bytes, which got interpreted as a truncated
archive.

The fix here is simple: we now always call `extract_pack_stream` when
`uncompressed_buffer_bytes_remaining` is zero before exiting the
skipping loop.

Fix potential overflow warning in cpio test_option_t (#2250)

Fixes an error from #2237.

[cpio test] Dates can be more than 12 bytes, depending on the locale (#2237)

In order to match cpio output, format the reference date with _at least_
12 bytes instead of _exactly_ 12 bytes. This should fix a gratuitous
test failure on certain systems that default to multi-byte locales.

Support ISOs with a non-standard PVD layouts (#2238)

The CSRG ISOs have a non-standard PVD layout with a 68-byte root
directory record (rather than the 34-byte record required by
ECMA119/ISO9660). I built a test image with this change and modified the
ISO9660 reader to accept it.

While I was working on the bid logic to recognize PVDs, I added a number
of additional correctness checks that should make our bidding a bit more
accurate. In particular, this should more than compensate for the
weakened check of the root directory record size.

Resolves #2232

Parse tar headers incrementally (#2127)

This rebuilds the tar reader to parse all header data incrementally as
it appears in the stream.

This definitively fixes a longstanding issue with unsupported pax
attributes. Libarchive must limit the amount of data that it reads into
memory, and this has caused problems with large unknown attributes. By
scanning iteratively, we can instead identify an attribute by name and
then decide whether to read it into memory or whether to skip it without
reading.

This design also allows us to vary our sanity limits for different pax
attributes (e.g., an attribute that is a single number can be limited to
a few dozen bytes while an attribute holding an ACL is allowed to be a
few hundred kilobytes). This allows us to be a little more resistant to
malicious archives that might try to force allocation of very large
amounts of memory, though there is still work to be done here.

This includes a number of changes to archive_entry processing to allow
us to consistently keep the _first_ appearance of any given value
instead of the original architecture that recursively cached data in
memory in order to effectively process all the data from back-to-front.

Resolves #1855
Resolves #1939

Fix a couple issues with creating PAX archives (#2228)

Note: this is a partial cherry-pick from
https://github.com/libarchive/libarchive/pull/2095, which I'm going to
go through and break into smaller pieces in hopes of getting some things
in while discussion of other things can continue.

There's basically two fixes here:

The first is to check for the presence of the WCS pathname on Windows
before failing since the conversion from WCS -> MBS might fail. Later
execution already handles such paths correctly.

The second is to set the converted link name on the target entry where
relevant. Note that there has been prior discussion on this here:
https://github.com/libarchive/libarchive/pull/2095/files#r1531599325

rar: fix UB negation overflow for INT32_MIN address (#2235)

certain rar files seem to have the lowest possible address here, so flip
the argument order to correctly evaluate this instead of invoking UB
(caught via sanitize=undefined)

---

the backtrace looks something like:

```
* frame #0: 0x00007a1e3898727b libarchive.so.13`execute_filter [inlined] execute_filter_e8(filter=<unavailable>, vm=<unavailable>, pos=<unavailable>, e9also=<unavailable>) at archive_read_support_format_rar.c:3640:47
    frame #1: 0x00007a1e3898727b libarchive.so.13`execute_filter(a=<unavailable>, filter=0x00007a1e39e2f090, vm=0x00007a1e31b1efd0, pos=<unavailable>) at archive_read_support_format_rar.c:0
    frame #2: 0x00007a1e38983ac3 libarchive.so.13`read_data_compressed [inlined] run_filters(a=0x00007a1e34209700) at archive_read_support_format_rar.c:3395:8
    frame #3: 0x00007a1e38983a9e libarchive.so.13`read_data_compressed(a=0x00007a1e34209700, buff=0x00007a1e31a01fd8, size=0x00007a1e31a01fd0, offset=0x00007a1e31a01fc0, looper=1) at archive_read_support_format_rar.c:2083:12
    frame #4: 0x00007a1e38981b10 libarchive.so.13`archive_read_format_rar_read_data(a=0x00007a1e34209700, buff=0x00007a1e31a01fd8, size=0x00007a1e31a01fd0, offset=0x00007a1e31a01fc0) at archive_read_support_format_rar.c:1130:11
    frame #5: 0x00006158bc5d30d3 file-roller`extract_archive_thread(result=0x00007a1e3711e2b0, object=<unavailable>, cancellable=0x00007a1e3870bf20) at fr-archive-libarchive.c:999:17
    frame #6: 0x00007a1e39928d6d libgio-2.0.so.0`run_in_thread(job=<unavailable>, c=<unavailable>, _data=0x00007a1e326e9740) at gsimpleasyncresult.c:899:5
    frame #7: 0x00007a1e3990614e libgio-2.0.so.0`io_job_thread(task=<unavailable>, source_object=<unavailable>, task_data=0x00007a1e2307fc20, cancellable=<unavailable>) at gioscheduler.c:75:16
    frame #8: 0x00007a1e399433bf libgio-2.0.so.0`g_task_thread_pool_thread(thread_data=0x00007a1e35c18ab0, pool_data=<unavailable>) at gtask.c:1583:3
    frame #9: 0x00007a1e39db77e8 libglib-2.0.so.0`g_thread_pool_thread_proxy(data=<unavailable>) at gthreadpool.c:336:15
    frame #10: 0x00007a1e39db5bfb libglib-2.0.so.0`g_thread_proxy(data=0x00007a1e378147d0) at gthread.c:835:20
    frame #11: 0x00007a1e3a0b5c7b ld-musl-x86_64.so.1`start(p=0x00007a1e31a02170) at pthread_create.c:208:17
    frame #12: 0x00007a1e3a0b8a8b ld-musl-x86_64.so.1`__clone + 47
```

note the 0xd which is 14 which is NegateOverflow in ubsan:

```
(lldb) x/1i $pc
->  0x7a1e3898727b: 67 0f b9 40 0d  other       ud1l   0xd(%eax), %eax
```

for reference, the totally legal rar file is
https://img.ayaya.dev/05WYGFOcRPN9 , and this seems to only crash when
extracted via file-roller (or inside nautilus)

xar: guard against file entries containing multiple name elements (#2236)

It appears that there are xar archives (in the form of Apple .pkg files)
that contain TOCs with duplicated name elements:

```xml
<file id="25">
  <data> ... </data>
  <type>file</type>
  <name>PackageInfo</name>
  <name>PackageInfo</name>
  <name>PackageInfo</name>
</file>
```

When libarchive encounters one such file, it will produce an
archive_entry named PackageInfoPackageInfoPackageInfo.

To produce a test archive, the XAR writer was modified to emit two name
elements.

Update ustar creation sanity check to use WCS path on Windows (#2230)

On Windows, the MBS pathname might be null if the string was set with a
WCS that can't be represented by the current locale. This is handled
properly by the rest of the code, but there's a sanity check that does
not make the proper distinction.

Note: this is a partial cherry-pick from
https://github.com/libarchive/libarchive/pull/2095, which I'm going to
go through and break into smaller pieces in hopes of getting some things
in while discussion of other things can continue.

Add unicode test for creating zip files on Windows (#2231)

There's no bug fix here - this just adds a test to verify that zip
creation when using the _w functions works as expected on Windows.

Note: this is a partial cherry-pick from
https://github.com/libarchive/libarchive/pull/2095, which I'm going to
go through and break into smaller pieces in hopes of getting some things
in while discussion of other things can continue.

Fuzzing: Expose `DONT_FAIL_ON_CRC_ERROR` as a CMake option and honor it in the rar5 decoder (#2229)

Hey,

the fuzzing infrastructure over at OSSFuzz builds libarchive with the
CMake option `-DDONT_FAIL_ON_CRC_ERROR=1`.

https://github.com/google/oss-fuzz/blob/e4643b64b3af4932bff23bb87afdfbac2a301969/projects/libarchive/build.sh#L35
This, unfortunatly, does not do anything since it's never been defined
as an option.

Building the fuzzers with CRC checks disabled should improve fuzzing
efficacy a bunch.

Thanks!

Use calloc instead of malloc to clear the memory from leftovers (#2207)

This ensures that the buffer is properly initialized and does not
contain any leftover data from previous operations. It is used later in
the `archive_entry_copy_hardlink_l` function call and could be
uninitialized.

configure.ac: autoupdate (#2223)

Clear up the autoconf warnings.

Update archive_entry_link_resolver to copy the "wide" pathname for hardlinks on Windows (#2225)

On Windows, if you are using `archive_entry_link_resolver` and give it
an entry that links to past entry whose pathname was set using a "wide"
string that cannot be represented by the current locale (i.e. WCS -> MBS
conversion fails), this code will crash due to a null pointer read. This
updates to use the `_w` function instead on Windows.

Note: this is a partial cherry-pick from
https://github.com/libarchive/libarchive/pull/2095, which I'm going to
go through and break into smaller pieces in hopes of getting some things
in while discussion of other things can continue.

Always use our supplied la_queue.h (#2222)

On legacy systems the OS supplied `sys/queue.h` may lack the required
macros, so to avoid having to verify if the version of queue.h is of
use, opt to always to `la_queue.h` which will match expectations.

Allows libarchive to build on legacy Darwin where `STAILQ_FOREACH` would
be missing from `sys/queue.h`.

Resolves #2220