Update 6.3.20 --> 6.3.21
PR: 165459 Approved by: Maintainer (Corey Halpin <chalpin@cs.wisc.edu>)
This commit is contained in:
parent
56338992b1
commit
9dd8c627df
Notes:
svn2git
2021-03-31 03:12:20 +00:00
svn path=/head/; revision=292204
@ -11,12 +11,12 @@
|
||||
# want fetchmailconf to work, define the X11 option.
|
||||
|
||||
PORTNAME= fetchmail
|
||||
PORTVERSION= 6.3.20
|
||||
PORTREVISION= 2
|
||||
PORTVERSION= 6.3.21
|
||||
CATEGORIES= mail ipv6
|
||||
MASTER_SITES= BERLIOS/fetchmail/ \
|
||||
http://mandree.home.pages.de/fetchmail/ \
|
||||
SUNSITE/system/mail/pop/fetchmail/
|
||||
MASTER_SITES= BERLIOS/${PORTNAME}/ \
|
||||
SF/${PORTNAME}/branch_6.3/ \
|
||||
http://mandree.home.pages.de/${PORTNAME}/ \
|
||||
SUNSITE/system/mail/pop/${PORTNAME}/
|
||||
|
||||
MAINTAINER= chalpin@cs.wisc.edu
|
||||
COMMENT= Batch mail retrieval utility for IMAP/POP3/ETRN/ODMR
|
||||
|
@ -1,2 +1,2 @@
|
||||
SHA256 (fetchmail-6.3.20.tar.xz) = 14767c897f613fb11e04a14154abcdeab5938e199da8aa68fbbf0fbc6639d720
|
||||
SIZE (fetchmail-6.3.20.tar.xz) = 1253216
|
||||
SHA256 (fetchmail-6.3.21.tar.xz) = dc1b92666df7bc4d6be3e66654e9894bcaa76527ea99183deabd9e11486e0f82
|
||||
SIZE (fetchmail-6.3.21.tar.xz) = 1254704
|
||||
|
@ -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;
|
Loading…
Reference in New Issue
Block a user