Item14689: Email::Address is deprecated, Email::Address::XS is the preferred module.
Current State: Closed
Released In: 2.1.7
Target Release: patch
This is a big issue for us. Some distributions (Debian, FreeBSD) are dropping CPAN:Email::Address
in upcoming releases. Others don't make the CPAN:Email::Address::XS
version available - Checked Centos, and Ubuntu. Though it can be found in some no-standard community libraries, that's not a good solution.
- 08 May 2018
As I commented in the pull request, it wouldn't be much to do a conditional require, and if the XS version of the module is not available then require the pure perl version. Also the Foswiki::Configure::Checkers::Email::MailMethod could check for the modules and warn if the pure perl version is in use.
- 09 May 2018
There is only a single code path that uses Email::Address:
which calls an internal
and in case
MAIL_METHOD is not =MailProgram
will try to send emails by itself ...
I'd suggest the following changes:
- remove dependency on Email::Address completely
- use Email::Address::XS if available
- if Email::Address::XS is not available, then disable the
Net::SMTP mailing methods
- and via
configure using an appropriate checker
- default to mail method
MailProgramm if possible and in case Email::Addres::XS is not present
- reject to send emails if no appropriate mailing method is available
Better don't send emails at all than using code known to cause security issues.
- 09 May 2018
My today's research has revealed that all roads lead to
and no viable alternatives are seen on the horizon.
So it seems that Michael's plan is the only good way to go with just one correction: for cases when neither a mail program nor
are available (think of the basic hostings) configure must provide the BIG RED BUTTON which would let the use of
after displaying a clear warning message. In a way it is similar to what George proposes with the difference that it won't be on by default and making use of it would require additional action from the admin.
- 09 May 2018
The CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7686
, see the NOTE there) and the Email::Address release notes (http://search.cpan.org/dist/Email-Address/Changes
) say that the current module isn't vulnerable if used in default configuration. This was reached at the expense of being not RFC 2822 conform any more. As most of Foswiki installations will probable use Email::Address in versions 1.908 or 1.909 in default configuration and there wasn't much complain about misparsing email addresses this seems to be an acceptable price.
The issue, or what has changed, is that the Email::Address Perl module is about to be removed during the next years. The recommended replacement is the Email::Address::XS module which has a drawback: It depends on a binary not written in Perl. Using the XS library would be the optimum but isn't probable always feasible.
Now, because the current, default Email::Address has no known vulnerability, is GPL licensed, and it wouldn't change Foswiki's behaviour, I would consider moving its parse() function to Foswiki as a possible fallback if Email::Address::XS isn't available.
- 10 May 2018
Daniel, I don't think that pulling some more external code into Foswiki is a good idea. I would even happily abandon huge pieces of internals in favor of some external solutions (like switch to Test2:: or Test:: frameworks, replace BuilderContrib
with Dist::Zilla, etc.)
In this situation it is not too much of a problem to disable email functionality when there is no safe way to deliver a message. After all, it would hurt only a handful of customers hosted on cheap/free hostings which are already limiting them beyond reason.
BTW, I think that in time they will pull the trigger on module removal there will pop up some alternative Perl-only solution.
- 10 May 2018
commented on github saying
(As "commenting is disabled" on https://foswiki.org/Tasks/Item14689
, I will write it here)
The CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7686, see the NOTE there) and the Email::Address release notes (http://search.cpan.org/dist/Email-Address/Changes) say that the current module isn't vulnerable if used in default configuration.
That is not truth, see NOTE section and References. It just mitigated one problem, but has not fixed it generally. Also there was discussion on list (linked to References) that last version of Email::Address did not fully fix this problem.
... I would consider moving its parse()
I hope you that you in foswiki project are not going to do such stupid thing.
Anyway, such irrational thinking (trying to copy possible-vulnerable code into other project) just motivated me to construct another input for Email::Address module which can cause Denial of Service.
Details are now public, see CVE-2018-12558:
The ML mentions that FreeBSD
and Debian distributions started removal of Email::Address module.
- 20 Jun 2018
Update 2020-02: I looked at misc. distributions in order to check whether they still ship Email::Address and whether a current version is available:
- (Linux) CentOS 6/8, Fedora 30+/Rawhide, openSUSE Leap 15.1/Tumbleweed, Debian Buster/Bullseye/Sid, Ubuntu Disco/Eoan/Focal all ship Email::Address 1.912
- The way Ubuntu/Debian package the Perl module, it's possible to explicitly install a current package from a newer official repository for Debian Jessie (EOL 2020-06)/Stretch (EOL 2022-06), Ubuntu Trusty (EOL 2022-04)/Xenial (EOL 2024-04)/Bionic (EOL 2028-04)
- CentOS 7 (EOL 2024-06) is the notable exception; whether a CentOS 8 package can be used here needs to be checked (but package structure looks like the one for Ubuntu/Debian, so forcing the installation of an EPEL CentOS 6 package should work.)
- (Linux) RHEL 6/7/8 do not list Email::Address packages at all in their respective package manifests
- There is a howto which describes the use of
cpanspec for RHEL/CentOS
- (NB: At least RHEL 8 comes with different versions of Perl (see "streams") -- whether, e.g., suitable third party repositories exist still needs to be checked)
- (BSD) FreeBSD has Email::Address 1.912
The above begs the question whether it's enough to point administrators to a short summary which explains how they can obtain/build their own distribution-specific package or directly install from CPAN.
- 17 Feb 2020
is a Email::Address::XS package built for alpine linux. It should be in the edge release soon and will be rolled into timlegge/docker-foswiki
- 21 Feb 2020
As an FYI Email::Address::XS is a lot more available than it was notable exceptions for CentoOS
- 15 Apr 2020