From: Matthias Andree <matthias.andree@gmx.de>
Date: Sun, 21 Aug 2011 13:07:48 +0000 (+0200)
Subject: Critical fix: don't embed NUL in unterminated last IMAP line.
X-Git-Url: http://pileus.org/git/?a=commitdiff_plain;h=617f00b557bca95687a7097b8d204ed0380f6d1d;p=~andy%2Ffetchmail

Critical fix: don't embed NUL in unterminated last IMAP line.

Found by Antoine Levitt.
---

diff --git a/NEWS b/NEWS
index 8f16e848..c2bf377b 100644
--- a/NEWS
+++ b/NEWS
@@ -118,6 +118,18 @@ NOTE THIS IS AN ALPHA RELEASE THAT HAS NOT BEEN THOROUGHLY TESTED!
 
 --------------------------------------------------------------------------------
 
+fetchmail-6.3.21 (not yet released):
+
+# CRITICAL BUG FIX
+* The IMAP client no longer inserts NUL bytes into the last line of a message
+  when it is not closed with a LF or CRLF sequence. Reported by Antoine Levitt.
+  As a side effect of the fix, and in order to avoid a full rewrite, fetchmail
+  will now CRLF-terminate the last line fetched through IMAP, even if it is
+  originally not terminated by LF or CRLF. This bears no relevance if your
+  messages end up in mbox, but adds line termination for storages (like Maildir)
+  that do not require that the last line be LF- or CRLF-terminated.
+
+
 fetchmail-6.3.20 (released 2011-06-06, 26005 LoC):
 
 # SECURITY BUG FIXES
diff --git a/transact.c b/transact.c
index 07aab00e..2b8d04f8 100644
--- a/transact.c
+++ b/transact.c
@@ -1416,7 +1416,15 @@ int readbody(int sock, struct query *ctl, flag forward, int len)
 	 * so we might end truncating messages prematurely.
 	 */
 	if (!protocol->delimited && linelen > len) {
+	    /* FIXME: HACK ALERT! This \r\n is only here to make sure the
+	     * \n\0 hunt works later on. The \n generated here was not
+	     * part of the original message!
+	     * The real fix will be to use buffer + length strings,
+	     * rather than 0-terminated C strings. */
+	    inbufp[len++] = '\r';
+	    inbufp[len++] = '\n';
 	    inbufp[len] = '\0';
+	    linelen = len;
 	}
 
 	len -= linelen;