** Bug fixes
- When converting timestamps to gzip file format (32-bit unsigned) or
- to time_t format (system-dependent), gzip now ignores out-of-range
- values instead of shoehorning them into the destination format,
- sometimes with undefined behavior. This affects timestamps before
+ gzip -d -S SUFFIX file.SUFFIX would fail for any upper-case byte in SUFFIX.
+ E.g., before, this command would fail:
+ $ :|gzip > kT && gzip -d -S T kT
+ gzip: kT: unknown suffix -- ignored
+ [bug present since the beginning]
+
+ When decompressing data in 'pack' format, gzip no longer mishandles
+ leading zeros in the end-of-block code. [bug introduced in gzip-1.6]
+
+ When converting from system-dependent time_t format to the 32-bit
+ unsigned MTIME format used in gzip files, if a timestamp does not
+ fit gzip now substitutes zero instead of the timestamp's low-order
+ 32 bits, as per Internet RFC 1952. When converting from MTIME to
+ time_t format, if a timestamp does not fit gzip now warns and
+ substitutes the nearest in-range value instead of crashing or
+ silently substituting an implementation-defined value (typically,
+ the timestamp's low-order bits). This affects timestamps before
1970 and after 2106, and timestamps after 2038 on platforms with
32-bit signed time_t. [bug present since the beginning]
gzip -d could segfault and/or clobber the stack, possibly leading to
arbitrary code execution. This affects x86_64 but not 32-bit systems.
This fixes CVE-2010-0001.
- For more details, see http://bugzilla.redhat.com/554418
+ For more details, see https://bugzilla.redhat.com/554418
gzip -d would fail with a CRC error for some valid inputs.
So far, the only valid input known to exhibit this failure was