This can matter on Windows:
- MSVC puts the binaries into subdirectories based on build type
(like "Debug" or "Release"), and then the test executables won't
find liblzma.dll because it's not in the working directory from
which the tests are run.
- With mingw-w64, liblzma.dll was in the working directory so the test
executables worked. However, the if the system happened to have
liblzma.dll in, for example, the Windows directory, then the DLL
search order might pick that instead.
Putting the shared library and test executables in the same directory
avoids these problems.
Reported-by: Frank <mail@franku.nl>
Fixes: https://github.com/tukaani-project/xz/pull/239
Previously, if an Index had more than PREALLOC_MAX Records, then
allocations were done in PREALLOC_DEFAULT chunks (512 Records).
That makes little sense in practice because it's likely that one
would run out of address space later. Return LZMA_MEM_ERROR error
pre-emptively if PREALLOC_MAX would be exceeded.
lzma_index_dup() copied the per-Stream flags but not the cached bitmask
for all Streams except the last one. As a result, lzma_index_checks() on
a duplicated multi-Stream Index reported only the Check type of its
final Stream.
Fixes: https://github.com/tukaani-project/xz/pull/238
If *in_pos > 0, the condition became more relaxed than it needed to be.
Fixes: 5005914f1acf ("liblzma: Index decoder: Reject an obviously-bad Number of>
Fixes: 0352dc7929b1 ("liblzma: Silence a compiler warning")
File info decoder knows Backward Size, so pass it to the Index decoder.
Now the Index decoder, when called from the file info decoder, won't
allocate a large amount of memory when Backward Size is tiny and the
Number of Records field contains a huge invalid value.
If a reasonable memory usage limit was set, the old code returned
LZMA_MEMLIMIT_ERROR if the value in Number of Records was too huge.
Now it results in LZMA_DATA_ERROR which is better.
If lzma_stream was initialized using lzma_index_decoder() or
lzma_file_info_decoder(), and lzma_memusage() was called after a few
Records had already been decoded, the return value was too low because
it was calculated based on the number of Records that haven't been
decoded yet. So near the end of a big Index, the return value would be
tiny compared to the actual memory usage.
It worked correctly in the primary use case, that is, after
LZMA_MEMLIMIT_ERROR. Thus, in practice this bug didn't matter much.
The headings are RTL but in some tables the rows were LTR because the
first strong char was LTR, like the "e" in "-0e". Add {RLM}{LRM}...{RLM}
to those columns ("-0" to "-9", and "-0e" to "-9e"):
sed -ri $'/^msgstr /{s/"(-[0-9]e?)"/"\u200f\u200e\\1\u200f"/}' ar.po
It's not perfect because groff doesn't treat RLM and LRM as zero-width
chars, and thus the columns are slightly misaligned. It's good enough
in practice still.
Thanks-to: Zayed Al-Saidi <zayed.alsaidi@gmail.com>
These workflows don't use any secrets other than GITHUB_TOKEN, which
only has the 'contents: read' permission. That is, if an action was
compromised, it shouldn't be able to modify the repository or steal any
secrets. I recognize that a compromised action isn't completely harmless
still. For example, the runners on GitHub have Internet access which the
action could abuse until the workflow timeout (currently 10 or 20 minutes)
expires.
Now we always use the most recent actions instead of ones that are
sometimes several months old. The hassle of updating the pinned
commit IDs goes away. The benefits feel bigger than the risks.
Link: https://github.com/tukaani-project/xz/pull/227
GitHub's actions/checkout@v6 is documented to need 'contents: read' but
it works without it too, probably because the repository is public.
Reported-by: GitHub user Alb3e3
Fixes: https://github.com/tukaani-project/xz/pull/230
There no point to try decoding further when the Index is clearly not
from a valid .xz file.
This also limits what index_decoder_memconfig() can return as the
memory usage. Very huge values aren't possible anymore. This affects
file_info_decoder_memconfig() in file_info.c where very huge values
aren't expected and could result in an integer overflow when not much
memory has actually been allocated. Now the overflow can only happen if
one manages to successfully allocate and fill a few exabytes of memory.
Reported-by: GitHub user jmestwa-coder
Fixes: https://github.com/tukaani-project/xz/pull/226
In two tables, the column headings are now narrower and
MANWIDTH=80 man --warnings po4a/man/ar/xz.1 > /dev/null
no longer warns.
Thanks-to: Zayed Al-Saidi <zayed.alsaidi@gmail.com>
Fixes: https://github.com/tukaani-project/xz/pull/220
This is required to handle strings that may contain invalid multibyte
sequences. For example, on GNU/Linux and FreeBSD 14 with UTF-8 locale:
$ printf "\201'A\n" | sed s/./x/ | hexdump -C
00000000 81 78 41 0a |.xA.|
That is, the first byte remains untouched and the ' is replaced with x.
This kind of string would result in inbalanced quotes in xzdiff. In the
C locale it works safely:
$ printf "\201'A\n" | LC_ALL=C sed s/./x/ | hexdump -C
00000000 78 27 41 0a |x'A.|
Similar changes were made in xzgrep in 2022 (see the commits 69d1b3fc2967
and 6a4a4a7d2667). Somehow xzdiff was forgotten even though this issue
was fixed in zdiff in gzip in 2022.
Co-authored-by: rootvector2 <dxbnaveed.k@gmail.com>
Fixes: https://github.com/tukaani-project/xz/pull/228
If --files=FILELIST or --files0=FILELIST was specified via an enrivonment
variable, it worked if there were no errors when reading from the file
FILELIST. However, if an error occurred when reading from FILELIST,
there was a use-after-free bug when printing the error message because
the memory containing the string "FILELIST" had been freed.
printf foo.xz > filelist.txt
XZ_OPT=--files=filelist.txt xz -l
Because filelist.txt doesn't end in a newline, the file list is seen as
invalid/truncated, resulting in an error message like this:
xz: ????????.txt: Unexpected end of input when reading filenames
The question marks are because the garbage string is masked using
tuklib_mask_nonprint(). After this commit, it works:
xz: filelist.txt: Unexpected end of input when reading filenames
Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>
Fixes: https://github.com/tukaani-project/xz/pull/223
For example, the following would run the "id" command:
xzgrep "--a='" "--b=;id;'" "pattern" foo.xz
The bug was inherited from gzip's zgrep. It was reported to bug-gzip by
Leenear. It was fixed in gzip in the commit cd74dc30f8cc by Paul Eggert.
Link: https://lists.gnu.org/archive/html/bug-gzip/2026-04/msg00032.html
This way the newer features are available on new enough kernels
even if the package is built against old <linux/landlock.h>.
Landlock ABI versions 4 and 6 would require an extended
struct landlock_ruleset_attr. No fallback is provided (or planned)
for those features.
Suggested-by: Omkhar Arasaratnam
