zgrep: don't assume traditional behavior with signal numbers

[debian/gzip] / NEWS

diff --git a/NEWS b/NEWS
index 02654390c10a89943aa64d17e8032c3e72e17986..08665006ca4d11e3b39313eed201a78700cfb960 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,38 @@ GNU gzip NEWS                                    -*- outline -*-
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** Bug fixes
+
+  gzip -d now decodes and checks header CRC16 checksums as specified by
+  the FHCRC section of Internet RFC 1952.
+
+  "gzip -d -S '' precious.gz" is now rejected immediately.  Before,
+  that command would emulate "rm -i precious.gz", but with an easily-
+  misunderstood prompt.  I.e., gzip would ask if it's ok to remove the
+  existing file, "precious.gz".  If you made the mistake of saying "yes",
+  it would remove that input file before attempting to uncompress it.
+
+  gzip -cdf now properly handles input consisting of gzip'd data followed
+  by uncompressed data.  Before it would output raw compressed input, too.
+  For example, now "(printf x|gzip; echo y)|gzip -dcf" prints "xy\n",
+  while before it would print "x<compressed data>y\n".
+
+
+* Noteworthy changes in release 1.4 (2010-01-20) [stable]
+
+** Bug fixes
+
+  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
+
+  gzip -d would fail with a CRC error for some valid inputs.
+  So far, the only valid input known to exhibit this failure was
+  compressed "from FAT filesystem (MS-DOS, OS/2, NT)".  In addition,
+  to trigger the failure, your memcpy implementation must copy in
+  the "reverse" order.
+
 
 * Noteworthy changes in release 1.3.14 (2009-10-30) [beta]