Overview

Request 923570 accepted

- Update to 6.4.22: [bsc#1190069, CVE-2021-39272]
* OPENSSL AND LICENSING NOTE:
- fetchmail 6.4.22 is compatible with OpenSSL 1.1.1 and 3.0.0.
OpenSSL's licensing changed between these releases from dual
OpenSSL/SSLeay license to Apache License v2.0, which is
considered incompatible with GPL v2 by the FSF. For
implications and details, see the file COPYING.
* SECURITY FIXES:
- CVE-2021-39272: fetchmail-SA-2021-02: On IMAP connections,
without --ssl and with nonempty --sslproto, meaning that
fetchmail is to enforce TLS, and when the server or an attacker
sends a PREAUTH greeting, fetchmail used to continue an
unencrypted connection. Now, log the error and abort the
connection. --Recommendation for servers that support
SSL/TLS-wrapped or "implicit" mode on a dedicated port
(default 993): use --ssl, or the ssl user option in an rcfile.
- On IMAP and POP3 connections, --auth ssh no longer prevents
STARTTLS negotiation.
- On IMAP connections, fetchmail does not permit overriding
a server-side LOGINDISABLED with --auth password any more.
- On POP3 connections, the possibility for RPA authentication
(by probing with an AUTH command without arguments) no longer
prevents STARTTLS negotiation.
- For POP3 connections, only attempt RPA if the authentication
type is "any".
* BUG FIXES:
- On IMAP connections, when AUTHENTICATE EXTERNAL fails and we
have received the tagged (= final) response, do not send "*".
- On IMAP connections, AUTHENTICATE EXTERNAL without username
will properly send a "=" for protocol compliance.

Loading...

Request History
Pedro Monreal Gonzalez's avatar

pmonrealgonzalez created request

- Update to 6.4.22: [bsc#1190069, CVE-2021-39272]
* OPENSSL AND LICENSING NOTE:
- fetchmail 6.4.22 is compatible with OpenSSL 1.1.1 and 3.0.0.
OpenSSL's licensing changed between these releases from dual
OpenSSL/SSLeay license to Apache License v2.0, which is
considered incompatible with GPL v2 by the FSF. For
implications and details, see the file COPYING.
* SECURITY FIXES:
- CVE-2021-39272: fetchmail-SA-2021-02: On IMAP connections,
without --ssl and with nonempty --sslproto, meaning that
fetchmail is to enforce TLS, and when the server or an attacker
sends a PREAUTH greeting, fetchmail used to continue an
unencrypted connection. Now, log the error and abort the
connection. --Recommendation for servers that support
SSL/TLS-wrapped or "implicit" mode on a dedicated port
(default 993): use --ssl, or the ssl user option in an rcfile.
- On IMAP and POP3 connections, --auth ssh no longer prevents
STARTTLS negotiation.
- On IMAP connections, fetchmail does not permit overriding
a server-side LOGINDISABLED with --auth password any more.
- On POP3 connections, the possibility for RPA authentication
(by probing with an AUTH command without arguments) no longer
prevents STARTTLS negotiation.
- For POP3 connections, only attempt RPA if the authentication
type is "any".
* BUG FIXES:
- On IMAP connections, when AUTHENTICATE EXTERNAL fails and we
have received the tagged (= final) response, do not send "*".
- On IMAP connections, AUTHENTICATE EXTERNAL without username
will properly send a "=" for protocol compliance.


Dirk Stoecker's avatar

dstoecker accepted request

openSUSE Build Service is sponsored by