2 files changed, 52 insertions, 1 deletions

diff --git a/mail/fetchmail/Makefile b/mail/fetchmail/Makefile
index 558bd76eff1f..325da4eb505c 100644
--- a/mail/fetchmail/Makefile
+++ b/mail/fetchmail/Makefile
@@ -12,7 +12,7 @@
 
 PORTNAME=	fetchmail
 PORTVERSION=	6.3.20
-PORTREVISION=	1
+PORTREVISION=	2
 CATEGORIES=	mail ipv6
 MASTER_SITES=	BERLIOS/fetchmail/ \
 		http://mandree.home.pages.de/fetchmail/ \
diff --git a/mail/fetchmail/files/patch-fix-embedded-NULs b/mail/fetchmail/files/patch-fix-embedded-NULs
new file mode 100644
index 000000000000..3629a4cc301f
--- /dev/null
+++ b/mail/fetchmail/files/patch-fix-embedded-NULs
@@ -0,0 +1,51 @@
+commit 138baebcae334c2c222c0d0299148fe1aef0315c
+Author: Matthias Andree <matthias.andree@gmx.de>
+Date:   Sun Aug 21 15:07:48 2011 +0200
+
+    Critical fix: don't embed NUL in unterminated last IMAP line.
+    
+    Found by Antoine Levitt.
+
+diff --git a/NEWS b/NEWS
+index e41a568..54d8c0b 100644
+--- a/NEWS
++++ b/NEWS
+@@ -56,6 +56,18 @@ removed from a 6.4.0 or newer release.)
+ 
+ --------------------------------------------------------------------------------
+ 
++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 d1e4f6a..ec8013a 100644
+--- a/transact.c
++++ b/transact.c
+@@ -1435,7 +1435,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;