exiwhat: Ensure the SIGUSR1 signal handler is safe.

[exim.git] / doc / doc-txt / ChangeLog

diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index b30b6abda2de61a00dd26ad58ac07474b8a6291f..3af14c39eaa018edf3bd4673c1ac8d16e5428f9c 100644 (file)
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -3,6 +3,36 @@ $Cambridge: exim/doc/doc-txt/ChangeLog,v 1.632 2010/06/12 15:21:25 jetmore Exp $
 Change log file for Exim from version 4.21
 -------------------------------------------
 
+Exim version 4.77
+-----------------
+
+PP/01 Solaris build fix for Oracle's LDAP libraries.
+      Bugzilla 1109, patch from Stephen Usher.
+
+TF/01 HP/UX build fix: avoid arithmetic on a void pointer.
+
+TK/01 DKIM Verification: Fix relaxed canon for empty headers w/o
+      whitespace trailer
+
+TF/02 Fix a couple more cases where we did not log the error message
+      when unlink() failed. See also change 4.74-TF/03.
+
+TF/03 Make the exiwhat support code safe for signals. Previously Exim might
+      lock up or crash if it happened to be inside a call to libc when it
+      got a SIGUSR1 from exiwhat.
+
+      The SIGUSR1 handler appends the current process status to the process
+      log which is later printed by exiwhat. It used to use the general
+      purpose logging code to do this, but several functions it calls are
+      not safe for signals.
+
+      The new output code in the SIGUSR1 handler is specific to the process
+      log, and simple enough that it's easy to inspect for signal safety.
+      Removing some special cases also simplifies the general logging code.
+      Removing the spurious timestamps from the process log simplifies
+      exiwhat.
+
+
 Exim version 4.76
 -----------------
 
@@ -31,7 +61,15 @@ PP/08 Condition negation of bool{}/bool_lax{} did not negate.  Fixed.
       Bugzilla 1104.
 
 TK/02 Bugzilla 1106: CVE-2011-1764 - DKIM log line was subject to a
-      format-string attack.
+      format-string attack -- SECURITY: remote arbitrary code execution.
+
+TK/03 SECURITY - DKIM signature header parsing was double-expanded, second
+      time unintentionally subject to list matching rules, letting the header
+      cause arbitrary Exim lookups (of items which can occur in lists, *not*
+      arbitrary string expansion). This allowed for information disclosure.
+
+PP/09 Fix another SIGFPE (x86) in ${eval:...} expansion, this time related to
+      INT_MIN/-1 -- value coerced to INT_MAX.
 
 
 Exim version 4.75