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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121005174515.GD15867@elie.Belkin
