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