ANNOUNCE: fetchmail 6.4.22 release candidate #3 available (security and crash fixes, IMAP protocol fixes)

Matthias Andree <[email protected]>
Newsgroups gmane.mail.fetchmail.user
Message-ID <YSuppKKKY8aETsPh__34962.5582968415$1630251482$gmane$org@ryzen.an3e.de>
Greetings,

The 6.4.22 release CANDIDATE #3 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.

rc2 fixes an IMAP protocol regression of rc1 that made it unable to 
download e-mail via IMAP in many circumstances. Reported by Corey 
Halpin.

rc3 fixes an IMAP protocol regression that struck when a server was not 
the very first server in a run. Reported by Stefan Esser.

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.rc3.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.rc3.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.22.rc3.tar.xz)= 1087a1c8ef8053f2deb97c17e2ab1a91fd3dd40fe275c7d6da0693bb1218fe13


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.
* 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]
* eo:    Keith Bowes [Esperanto]
* fr:    Frédéric Marchal [French]
* pl:    Jakub Bogusz [Polish]
* sv:    Göran Uddeborg [Swedish]

# CREDITS:
* Thanks for testing the release candidates and bug reports to:
  Corey Halpin, Stefan Esser.
--------------------------------------------------------------------------------

Happy fetches,
Matthias

_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmErqaMACgkQ5BKxVu/z
hVqQRQ//ZIFwGpqpY8J+IJi/HxQLvzWjU9V61uMz3yWb7sl9IZ0xS8Fyrqv2XW5P
Q6J99ZMzgZjE894DCS8tnvqBrcTc+zgpuG9wP148ofQWXqSR21MN6jqr8txIRfL+
0C70ss3oXEzdseESPs2XOr9AzpM+XR3hrbRArRMsrLfXrUUnZQGWN0RrNQU1Ow/j
zY/mGS+OU04rzzISBi5QOTINptzNi+ArGiAWO1kD0v+ONflOat6ljFntV6tQgrbm
YgdEoxhrHyZ8At2YOp2a51lks4fvr3Iy5ZgL0WYQrCZY+OE/nAWx8CpoavWA6lTV
BnevTwNYjzcu/xkJ7uaXexlgVab6/Lr+UuK+3bkT4Anfb4s9zRXa6G/k7UQ5oe3B
VN+ComlJAW9cMRnre268VQzd3JqeS02Me7UaUmm5fqSuNecxkAZ12ttywh5OyaCw
U6Bo04aDeXfsZV19tQd2PBMlII5YX4aQcUO0vzljSzOzI80+nhNHQhSXuqX9Tqf0
9JWCww/nLn5bz4oX1rwPzxVXVlJh1xhnBSL4Aws/s8Q4w8iDeLkXPTxBTiHf9Mhg
l3CHcu0+u4BcH2fsYODhViH0cXc2MXV9xsyntXTv3bgEkrcDB7HOAz4qMYeE0r2j
+P5po6smR1Wtp0Hdr+6swMPmPgnsQLRgpWrAqQaQ3RbXRA/u6UI=
=G5w9
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.