fetchmail-6.4.22

[Bruce Dubbs]

New point version.

[ken@…]

from README.txt:

etchmail-6.4.22 (released 2021-09-13, 30201 LoC):

# 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.
  --Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why 
  TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email 
  Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian 
  Schinzel.  The paper did not mention fetchmail.

* 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.
* On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server 
  advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4 
  has not supported and does not support the separate challenge/response with 
  command continuation)
* On IMAP connections, when --auth external is requested but not advertised by 
  the server, log a proper error message.
* Fetchmail no longer crashes when attempting a connection with --plugin "" or 
  --plugout "".
* Fetchmail no longer leaks memory when processing the arguments of --plugin or 
  --plugout on connections.
* On POP3 connections, the CAPAbilities parser is now caseblind.
* Fix segfault on configurations with "defaults ... no envelope". Reported by  
  Bjørn Mork. Fixes Debian Bug#992400.  This is a regression in fetchmail 6.4.3
  and happened when plugging memory leaks, which did not account for that the 
  envelope parameter is special when set as "no envelope". The segfault happens
  in a constant strlen(-1), triggered by trusted local input => no vulnerability.
* Fix program abort (SIGABRT) with "internal error" when invalid sslproto is 
  given with OpenSSL 1.1.0 API compatible SSL implementations.
# CHANGES:
* IMAP: When fetchmail is in not-authenticated state and the server volunteers 
  CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail 
  must and will re-probe explicitly.)
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
  do not match, emit a warning and continue. Closes Gitlab #31.
  (cherry-picked from 6.5 beta branch "legacy_6x")
* fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997
  recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer,
  placing --sslproto tls1.2+ more prominently.
  The defaults shall not change between 6.4.X releases for compatibility.
 TRANSLATIONS: language translations were updated by these fine people:
* sq:    Besnik Bleta [Albanian]
* cs:    Petr Pisar [Czech]
* eo:    Keith Bowes [Esperanto]
* fr:    Frédéric Marchal [French]
* pl:    Jakub Bogusz [Polish]
* sv:    Göran Uddeborg [Swedish]

Marking as elevated, although BLFS recommended the '--ssl' option in our 11.0 release and if using that there should not be a need to treat this as a security update.

[ken@…]

@aaab0a4e7bb642520105ce8210ecd799fe1cea89 11.0-66

[ken@…]

Advisory SA 11.0-010.