There are no functional changes in these files, but they are however
linked against OpenSSL 1.1.1 and need to be re-shipped before we remove
the legacy library.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 6.4.34 to 6.4.36
- Update of rootfile nor required
- Changelog
fetchmail-6.4.36 (released 2023-01-28, 31710 LoC):
(in alphabetical order of language codes):
* cs: Petr Pisar [Czech]
* es: Cristian Othón Martínez Vera [Spanish]
* fr: Frédéric Marchal [French]
* ja: Takeshi Hamasaki [Japanese]
* pl: Jakub Bogusz [Polish]
* ro: Remus-Gabriel Chelu [Romanian]
* sq: Besnik Bleta [Albanian]
* sv: Göran Uddeborg [Swedish]
fetchmail-6.4.35 (released 2023-01-04, 31707 LoC):
* Fetchmail now warns about OpenSSL before 1.1.1s or 3.0.7,
and rejects wolfSSL older than 5.5.1.
(in reverse alphabetical order of language codes so as not to prefer people):
* sv: Göran Uddeborg [Swedish]
* eo: Keith Bowes [Esperanto]
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Update from version 6.4.32 to 6.4.34
- Update of rootfile not required.
- Changelog
Fetchmail Release Notes
# ADVANCE WARNING OF FEATURES TO BE REMOVED OR CHANGED IN FUTURE VERSIONS
(There are no plans to remove features from a 6.4.X release, but they may be
removed from a 6.5.0 or newer release.)
* Future fetchmail releases may require compilers and operating systems
that adhere to standards issued 2011 or later.
(Currently, C89 and Single Unix Specification V2 should suffice.)
* Future fetchmail releases may tighten up security and lean towards
it a bit more by, for instance, implementing recommendations from
RFC-7817 or RFC-8314. This may, for instance, require that TLS v1.1
or newer be used.
* 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.
* IMAP2 and IMAP4 (not IMAP4r1) are obsolete, support may be removed from a
future fetchmail version.
* RPOP is obsolete, support will be removed from a future fetchmail release.
* 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.
* Kerberos 5 support may be removed from a future fetchmail release.
* The --principal option 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.
* The --bsmtp - mode of operation may be removed in a future release.
* SSLv3 support may be removed from a future fetchmail release. It has been
obsolete for many years and found insecure. Use TLS.
* Fetchmailconf is deprecated and will be removed from a future release.
* Fetchmail does not guarantee compatibility with EOL OpenSSL versions. Support
for end-of-life OpenSSL versions may be removed even from patchlevel releases.
* Nonstandard authentication schemes (such as RPA) may be removed from future
fetchmail versions.
* Nonstandard protocol extensions (such as SDPS/*ENV) may be removed from future
fetchmail versions.
* Future fetchmail releases (even minor ones) may change undocumented parts of
the .netrc parser in incompatible ways to enhance compatibility with typical
ftp(1) .netrc parsers.
* Apparently OPIE is dying. I only have this support on FreeBSD, and
FreeBSD 14 (slated for release in 2023) is about to remove it.
# KNOWN BUGS AND WORKAROUNDS
* Fetchmail does not handle messages without Message-ID header well
(See sourceforge.net bug #780933)
* Fetchmail currently uses 31-bit signed integers in several places
where unsigned and/or wider types should have been used, for instance,
for mailbox sizes, and misreports sizes of 2 GibiB and beyond.
Fixing this requires C89 compatibility to be relinquished.
* BSMTP is mostly untested and errors can cause corrupt output.
* Fetchmail does not track pending deletes across crashes.
* The command line interface is sometimes a bit stubborn, for instance,
fetchmail -s doesn't work with a daemon running.
* Linux systems may return duplicates of an IP address in some circumstances if
no or no global IPv6 addresses are configured.
(No workaround. Ubuntu Bug#582585, Novell Bug#606980.)
* Kerberos 5 may be broken, particularly on Heimdal, and provide bogus error
messages. This will not be fixed, because the maintainer has no Kerberos 5
server to test against. Use GSSAPI.
* For IMAP connections, fetchmail will print "will idle after poll" in
verbose mode even though --idle is not given, as an artifact of the 6.4.22
security fixes. Fetchmail means "could idle after poll", but this would
have required another loop through the translators.
* aka ... hostnames are not considered for upstream server X.509 certificate
verification, aka was meant for alias detection with multidrop mailboxes.
* When compiled against wolfSSL, some diagnostics and messages of fetchmail are
hardcoded to read "OpenSSL"; this was found only after the call for
translations had been sent out already.
* FreeBSD's OPIE implementation cannot be found when using a C++ compiler.
This should not affect the normal build, which uses a C compiler.
fetchmail-6.4.34 (released 2022-10-15, 31701 LoC):
# CRITICAL BUG FIXES:
* When an SMTP receiver refuses delivery, a message would be deleted from
the mail store in spite of a softbounce option that is enabled.
Bug report, analysis and patch by Horváth Zsolt. Gitlab, fixes#50.
# BUILD NOTE:
* If you are reusing config.cache from prior builds, this may cause
issues with finding Python or some libraries. In case of trouble,
remove config.cache and retry.
# TRANSLATIONS: language translations were updated by this fine person:
* sr: Мирослав Николић (Miroslav Nikolić) [Serbian]
fetchmail-6.4.33 (released 2022-08-27, 31696 LoC):
# TRANSLATIONS: language translations were updated by this fine person:
* fr: Frédéric Marchal [French]
# CONTRIBUTED SCRIPT CHANGES:
* contrib/fetchsetup improvements by Matěj Cepl
* contrib/runfetchmail improvements by Matěj Cepl
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 6.4.19 to 6.4.32
- Update of rootfile not required
- Changelog - range of security and bug fixes
fetchmail-6.4.32 (released 2022-07-30, 31696 LoC):
# FIXES:
* Use configure to find rst2html, some systems install it only with .py suffix,
others only without, and some install both.
* Update README.maintainer
# TRANSLATIONS: language translations were updated by these fine people:
(in alphabetical order of language codes so as not to prefer people):
* cs: Petr Pisar [Czech]
* es: Cristian Othón Martínez Vera [Spanish]
* ja: Takeshi Hamasaki [Japanese]
* pl: Jakub Bogusz [Polish]
* ro: Remus-Gabriel Chelu [Romanian]
* sq: Besnik Bleta [Albanian]
* sv: Göran Uddeborg [Swedish]
fetchmail-6.4.31 (released 2022-07-16, 31694 LoC):
# BUG FIXES:
* Try to fix ./configure --with-ssl=... for systems that have multiple OpenSSL
versions installed. Issues reported by Dennis Putnam.
* The netrc parser now reports its errors to syslog or logfile when appropriate,
previously it would always log to stderr.
* Add error checking to .netrc parser.
# CHANGES:
* manpage: use .UR/.UE macros instead of .URL for URIs.
* manpage: fix contractions. Found with FreeBSD's igor tool.
* manpage: HTML now built with pandoc -> python-docutils
(manServer.pl was dropped)
fetchmail-6.4.30 (released 2022-04-26, 31666 LoC):
# BREAKING CHANGES:
* Bump wolfSSL minimum required version to 5.2.0 to pull in security fix.
# CHANGES:
* Using OpenSSL 1.* before 1.1.1n elicits a compile-time warning.
* Using OpenSSL 3.* before 3.0.2 elicits a compile-time warning.
* configure.ac was tweaked in order to hopefully fix cross-compilation issues
report, and different patch suggested, by Fabrice Fontaine,
https://gitlab.com/fetchmail/fetchmail/-/merge_requests/42
# TRANSLATIONS: language translations were updated by this fine person:
* ro: Remus-Gabriel Chelu [Romanian]
fetchmail-6.4.29 (released 2022-03-20, 31661 LoC):
# TRANSLATIONS: language translations were updated by this fine person:
* vi: Trần Ngọc Quân [Vietnamese]
fetchmail-6.4.28 (released 2022-03-05, 31661 LoC):
# DOCUMENTATION:
* Fix a typo in the manual page, courtesy of Jeremy Petch.
# TRANSLATIONS: language translations were updated by this fine person:
* es: Cristian Othón Martínez Vera [Spanish]
fetchmail-6.4.27 (released 2022-01-26, 31661 LoC):
# BREAKING CHANGES:
* Bump wolfSSL minimum required version to 5.1.1 to pull in security fix.
# TRANSLATIONS: language translations were updated by this fine person:
* ro: Remus-Gabriel Chelu [Romanian]
fetchmail-6.4.26 (released 2021-12-26, 31661 LoC):
# FIXES:
* When using wolfSSL 5.0.0, work around a bug that appears to hit wolfSSL when
receiving handshake records while still in SSL_peek(). Workaround is to read
1 byte and cache it, then call SSL_peek() again.
This affects only some servers. https://github.com/wolfSSL/wolfssl/issues/4593
# TRANSLATIONS: language translations were updated by this fine person:
* sr: Мирослав Николић (Miroslav Nikolić) [Serbian]
fetchmail-6.4.25 (released 2021-12-10, 31653 LoC):
# BREAKING CHANGES:
* Since distributions continue patching for LibreSSL use, which cannot be
linked legally, block out LibreSSL in configure.ac and socket.c, and
refer to COPYING, unless on OpenBSD (which ships it in the base system).
OpenSSL and wolfSSL 5 can be used. SSL-related documentation was updated, do
re-read COPYING, INSTALL, README, README.packaging, README.SSL.
* Bump OpenSSL version requirement to 1.0.2f in order to safely remove
the obsolete OpenSSL flag SSL_OP_SINGLE_DH_USE. This blocks out 1.0.2e and
older 1.0.2 versions. 1.0.2f was a security fix release, and 1.0.2u is
publicly available from https://www.openssl.org/source/old/1.0.2/
* Some of the configure.ac fiddling MIGHT have broken cross-compilation
again. The maintainer does not test cross-compiling fetchmail; if you
have difficulties, try setting PKG_CONFIG_LIBDIR to the pkg-config path
containing your target/host libraries, or see if --with-ssl-prefix or
--with-wolfssl-prefix, or overriding LDFLAGS/LIBS/CPPFLAGS, can help.
Feedback solicited on compliant systems that are before end-of-life.
# BUG FIXES:
* 6.4.24's workaround for OpenSSL 1.0.2's X509_V_FLAG_TRUSTED_FIRST flag
contained a typo and would not kick in properly.
* Library and/or rpath setting from configure.ac was fixed.
# ADDITIONS:
* Added an example systemd unit file and instructions to contrib/systemd/
which runs fetchmail as a daemon with 5-minute poll intervals.
Courteously contributed by Barak A. Pearlmutter, Debian Bug#981464.
* fetchmail can now be used with wolfSSL 5's OpenSSL compatibility layer,
see INSTALL and README.SSL. This is considered experimental.
Feedback solicited.
# CHANGES:
* The getstats.py dist-tool now counts lines of .ac and .am files.
* ./configure --with-ssl now supports pkg-config module names, too. See INSTALL.
# TRANSLATIONS: language translations were updated by these fine people:
(in reverse alphabetical order of language codes so as not to prefer people):
* sv: Göran Uddeborg [Swedish]
* sq: Besnik Bleta [Albanian]
* pl: Jakub Bogusz [Polish]
* ja: Takeshi Hamasaki [Japanese]
* fr: Frédéric Marchal [French]
* eo: Keith Bowes [Esperanto]
* cs: Petr Pisar [Czech]
fetchmail-6.4.24 (released 2021-11-20, 30218 LoC):
# OPENSSL AND LICENSING NOTE:
> see fetchmail-6.4.22 below, and the file COPYING.
Note that distribution of packages linked with LibreSSL is not feasible
due to a missing GPLv2 clause 2(b) exception.
# COMPATIBILITY:
* Bison 3.8 dropped yytoknum altogether, breaking compilation due to a
warning workaround. Remove the cast of yytoknum to void. This may cause
a compiler warning to reappear with older Bison versions.
* OpenSSL 1.0.2: Workaround for systems that keep the expired DST Root CA X3
certificate in its trust store because OpenSSL by default prefers the
untrusted certificate and fails. Fetchmail now sets the
X509_V_FLAG_TRUSTED_FIRST flag (on OpenSSL 1.0.2 only).
This is workaround #2 from the OpenSSL Blog. For details, see both:
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
NOTE: OpenSSL 1.0.2 is end of life, it is assumed that the OpenSSL library
is kept up to date by a distributor or via OpenSSL support contract.
Where this is not the case, please upgrade to a supported OpenSSL version.
# DOCUMENTATION:
* The manual page was revised after re-checking with mandoc -Tlint, aspell,
igor. Some more revisions were made for clarity.
# TRANSLATIONS: language translations were updated by these fine people:
* sv: Göran Uddeborg [Swedish]
* pl: Jakub Bogusz [Polish]
* fr: Frédéric Marchal [French]
* cs: Petr Pisar [Czech]
* eo: Keith Bowes [Esperanto]
* ja: Takeshi Hamasaki [Japanese]
fetchmail-6.4.23 (released 2021-10-31, 30206 LoC):
# USABILITY:
* For common ssh-based IMAP PREAUTH setups (i. e. those that use a plugin
- no matter its contents - and that set auth ssh), change the STARTTLS
error message to suggest sslproto '' instead.
This is a commonly reported issue after the CVE-2021-39272 fix in 6.4.22.
Fixes Redhat Bugzilla 2008160. Fixes GitLab #39.
# TRANSLATIONS: language translations were updated by these fine people:
* ja: Takeshi Hamasaki [Japanese]
* sr: Мирослав Николић (Miroslav Nikolić) [Serbian]
fetchmail-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]
fetchmail-6.4.21 (released 2021-08-09, 30042 LoC):
# REGRESSION FIX:
* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of
messages logged to buffered outputs, from --logfile and --syslog.
This also caused lines in the logfile to run into one another because
the fragment containing the '\n' line-end character was usually lost.
Reason is that on all modern systems (with <stdarg.h> header and vsnprintf()
interface), the length of log message fragments was added up twice, so
that these ended too deep into a freshly allocated buffer, after the '\0'
byte. Unbuffered outputs flushed the fragments right away, which masked the
bug.
fetchmail-6.4.20 (released 2021-07-28, 30042 LoC):
# SECURITY FIX:
* When a log message exceeds c. 2 kByte in size, for instance, with very long
header contents, and depending on verbosity option, fetchmail can crash or
misreport each first log message that requires a buffer reallocation.
fetchmail then reallocates memory and re-runs vsnprintf() without another
call to va_start(), so it reads garbage. The exact impact depends on
many factors around the compiler and operating system configurations used and
the implementation details of the stdarg.h interfaces of the two functions
mentioned before. To fix CVE-2021-36386.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
Bumping across one of our scripts with very long trailing whitespaces, I
thought it might be a good idea to clean these up. Doing so, some
missing or inconsistent licence headers were fixed.
There is no need in shipping all these files en bloc, as their
functionality won't change.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
* Add a Summary and Services field to all pak lfs files
* Replace occurances of INSTALL_INITSCRIPT with new INSTALL_INITSCRIPTS
macro in all pak lfs files.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
- Update from 6.3.26 (2013-04-23) to 6.4.19 (2021-04-24)
- Update rootfile
- Delete fetchmail-6.3.26-permit-build-without-ssl3.patch as it is not
needed with version 6.4.19
- Added command to use python3 to lfs
- Changelog is too large to include here
Full details can be found in NEWS file in the source tarball
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Not sure why this has ever been there. This simply makes it
nicer to read and edit because we can have line-breaks now.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Most of these files still used old dates and/or domain names for contact
mail addresses. This is now replaced by an up-to-date copyright line.
Just some housekeeping... :-)
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
