[Fetchmail-announce] ANNOUNCE: fetchmail 6.4.22 release candidate available (security and crash fixes)

[Matthias A. <mat...@gm...>]

Greetings,

The 6.4.22 release CANDIDATE of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It contains security fixes for CVE-2021-39272 and fixes up several protocol
violations along the way, fixes some configuration-based crashes (SIGSEGV) and
updates the documentation.

This version has quite extensive changes for a patchlevel release.

Note that security recommendations in README.SSL were changed to achieve higher
security from the configuration. Built-in defaults do not change.

Please test this thoroughly and report your findings so we can be sure that
6.4.22 will be a good release.  It has been mailed out to the translation
project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc1.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc1.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.22.rc1.tar.xz)= 96634167a0c21673abaa8c76e669fb5799266c19f784c03a760c2048681cd3b3

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.22 (not yet released):

# SECURITY FIXES:
* 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.

# 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.
---------------------------------------------------------------------------------

Happy fetches,
Matthias