Update 6.3.20 --> 6.3.21

PR:		165459
Approved by:	Maintainer (Corey Halpin <chalpin@cs.wisc.edu>)

1 files changed, 0 insertions, 51 deletions

diff --git a/mail/fetchmail/files/patch-fix-embedded-NULs b/mail/fetchmail/files/patch-fix-embedded-NULs
deleted file mode 100644
index 3629a4cc301f..000000000000
--- a/mail/fetchmail/files/patch-fix-embedded-NULs
+++ /dev/null
@@ -1,51 +0,0 @@
-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;