fetchmail 6.3.11 security fix release available (STABLE)

Matthias Andree <[email protected]> Thu, 6 Aug 2009 02:02:52 +0200
Newsgroups gmane.mail.fetchmail.announce
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

I am announcing the release of fetchmail 6.3.11.  This new stable
version of fetchmail fixes a security bug, CVE-2009-2666, and two other
issues, see below for details.

The software is available from:
<http://developer.berlios.de/project/showfiles.php?group_id=1824>

The fetchmail home pages are:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

These are the relevant changes in 6.3.11 since 6.3.10;
unless otherwise noted, changes to this release were made by Matthias Andree:

# SECURITY BUGFIXES
* CVE-2009-2666: SSL NUL prefix impersonation attack through NULs in a
  part of a X.509 certificate's CommonName and subjectAltName fields. These
  fields use opaque strings with a separate length field, so that the NUL
  character isn't a special character inside the certificate. Fetchmail, being
  written in the C language, used to treat these strings as C strings
  nonetheless, so that the domain comparison would end at the first embedded NUL
  character, rather than at the real end of the string.
    Fetchmail will now abort certificate verification as failed if NULs are
  encountered inside either of these fields regardless of their position, and
  drop the connection even if --sslcertck is not used, because NUL is not a
  valid character in legitimate DNS names.
  See fetchmail-SA-2009-01.txt for details, including a minimal patch.

# BUGFIXES
* Remove the spurious message "message delimiter found while scanning headers".
  RFC-5322 syntax states that the delimiter is part of the body, and the body is
  optional.
* Convert all non-printable characters in certificate Subject/Issuer
  Common Name or Subject Alternative Name fields to ANSI-C hex escapes (\xnn,
  where nn are hex digits).

# TRANSLATION UPDATES AND ADDITIONS (ordered by language name):
* [zh_CN] Chinese/Simplified (Ji ZhengYu)
* [es]    Spanish/Castilian (Francisco Molinero)

# ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
(There are no plans to remove features from a 6.3.X release, but they may be
removed from a 6.4.0 or newer release.)
* The MX and host alias DNS lookups that fetchmail performs in multidrop mode
  are based on assumptions that are rarely met in practice, somewhat defective,
  deprecated and may be removed from a future fetchmail version.
  They have never supported IPv6 (including IPv6-mapped IPv4).
  Non-DNS based alias keywords such as "aka" will remain in fetchmail.
* The monitor and interface options may be removed from a future fetchmail
  version as they are not reasonably portable across operating systems.
* POP2 is obsolete, support will be removed from a future fetchmail version.
* RPOP is obsolete, support will be removed from a future fetchmail release.
* --sslcertck will become a default setting in a future fetchmail version.
* --sslfingerprint may be removed from a future fetchmail version, because it's
  just too easily abused to create a false sense of security.
* The multidrop To/Cc guessing code along with the fragile duplicate suppressor
  is deprecated and may be removed from a future release.
* The "envelope Received" option may be removed from a future release, because
  the Received header was never meant to be machine-readable, the format varies
  widely, and various other differences in behavior make parsing Received an
  unreliable undertaking. The envelope option as such will remain though, in
  order to support Delivered-To, X-Envelope-To, X-Original-To and similar.
  See also <http://home.pages.de/~mandree/mail/multidrop>.
* The --enable-fallback (fall back to MDA if MTA unavailable) will be removed
  from a future fetchmail release, because it makes fetchmail's behavior
  inconsistent and confusing.
* The "protocol auto" default inside fetchmail may be removed from a future
  fetchmail release. Explicit configuration of the protocol is recommended.
* Kerberos IV support may be removed from a future fetchmail release.
* SIGHUP wakeup support may be removed from a future fetchmail release and
  cause fetchmail to terminate - it was broken for many years.
* Support for operating systems that are not sufficiently POSIX compliant may be
  removed or operation on such systems may be suboptimal for future releases.
  This means that fetchmail may only continue to work on C99 and POSIX 2001
  based systems.
* The maintainer may migrate fetchmail to C++ with STL or C#, and impose further
  requirements (dependencies), such as Boost or other class libraries.
* The softbounce option default will change to "false" in the next release.

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkp6HawACgkQvmGDOQUufZVGJwCfUVdPy62qU0zffx8I4RPFGlNg
KosAoMaqkDewu0x/+QSpCLL5yz5eg8fU
=lTMq
-----END PGP SIGNATURE-----