Bug#678624: pu: package xz-utils/5.0.0-3
Hi,
In June, Jonathan Nieder wrote:
> +xz-utils (5.0.0-3) stable; urgency=low
> +
> + * Fixes from upstream:
Ping. A number of these are important to me:
> + * liblzma:
> + - lzma_easy_buffer_encode() and lzma_stream_buffer_encode()
> + avoid writing Blocks with empty compressed data that xz and
> + liblzma versions before 5.0.2 cannot read.
Without this patch, using python-lzma in a naive way to compress an
empty file produces an XZ file that many implementations (including
the one currently in squeeze) cannot decompress.
> + - The LZMA2 decoder skips Blocks with empty compressed data
> + instead of rejecting them.
This patch improves compatibility by decompressing those files. (*)
> + - Validates encoder arguments better. It is harder to segfault
> + or create a corrupt XZ file [...]
This patch improves compatibility by catching some misuses of the API
that have no valid meaning. (**)
> + - bcj: Fix possibility of incorrect LZMA_BUF_ERROR (reported in
> + XZ Embedded as Fedora bug 735408).
An important one --- avoids spurious errors when one is unlucky about
how buffer sizes line up. Improves compatibility.
> + - Plugs a memory leak in lzma_stream_encoder().
Small memory leak, but the patch is obviously correct.
> + - lzma_index_init() returns NULL instead of segfaulting on
> + allocation failure.
Not very important unless liblzma is used in a process mapping
interesting things at low addresses, but the patch is obviously
correct.
> + * docs/examples/xz_pipe_decompress.c checks that the last
> + lzma_code() call returned LZMA_STREAM_END to avoid mistaking a
> + file without a proper footer for a valid XZ file.
Documentation fix. Programs copying the example would not notice
files that are truncated, for example due to a failed download. See
http://thread.gmane.org/gmane.comp.compression.xz.devel/85/focus=94
> + * "xz -v -v --list" does not free() filter options unless the
> + filter options array has been initialized. [...]
Might be a security bug (invalid free()s overflowing on-stack array).
Not obvious how to exploit it, though.
> + * xzegrep and xzfgrep perform extended regex and fixed-string
> + matches, respectively. (The previous behavior was to always
> + use basic regexes.)
Usability fix. Not too important but obviously corret.
> + * The exit status from “xzdiff foo.xz bar.xz” reflects whether
> + files differ. Thanks to Peter Pallinger. Closes: #635501.
Another simple usability fix. (***)
> + * xzgrep does not fail just because the decompressor has died
> + with SIGPIPE due to some unconsumed output. This makes the
> + exit status from commands such as "xzgrep -q" more predictable.
This is needed for "xzgrep -q" and xzgrep of binary files to be
actually usable for scripts. Especially in the latter case it is
easy to write a script and test it without ever running into this,
then run into it later. :/
> + * The Czech “xz --help” output uses a more correct term for files
> + with holes. Thanks to Petr Hubený. Closes: #605762.
> + * The Italian diagnostic for an invalid --format argument lost an
> + extra 'N'.
Minor (one-word) translation fixes.
> + * debian/rules: "chmod +x tests/test_scripts.sh" for new xzdiff
> + tests.
Supporting (***) --- quilt doesn't track the +x bit.
> + * debian/symbols: Bump the minimal versions for LZMA2 encoder
> + functions that reject more bad arguments and skip empty blocks.
Supporting (*) and (**).
> + * liblzma-dev: Install an appropriate library for static linking
> + instead of the decompression-only version used to build xzdec.
> + Thanks to Anton Tolchanov. Closes: #673001.
This one's embarassing and what prompted me to look again at the state
of the package in squeeze in the first place.
Thoughts? Anything I can do to help get this reviewed?
Jonathan
Reply to: