Item14689: Email::Address is deprecated, Email::Address::XS is the preferred module.

See https://github.com/foswiki/distro/pull/20

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.

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

-- GeorgeClark - 09 May 2018

There is only a single code path that uses Email::Address: Foswiki::Net::sendEmail which calls an internal _installMailHandler and in case MAIL_METHOD is not =MailProgram will try to send emails by itself ...

I'd suggest the following changes:

1. remove dependency on Email::Address completely
2. use Email::Address::XS if available
3. if Email::Address::XS is not available, then disable the Net::SMTP mailing methods
   • in Foswiki::Net::_installMailHandler
   • and via configure using an appropriate checker
4. default to mail method MailProgramm if possible and in case Email::Addres::XS is not present
5. 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.

-- MichaelDaum - 09 May 2018

My today's research has revealed that all roads lead to Email::Address 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 Email::Address::XS are available (think of the basic hostings) configure must provide the BIG RED BUTTON which would let the use of Email::Addres 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.

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

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

-- VadimBelman - 10 May 2018

Pali 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: https://www.mail-archive.com/[email protected]/msg00544.html

Happy hacking!

---

The ML mentions that FreeBSD and Debian distributions started removal of Email::Address module.

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

-- MarkusUeberall - 17 Feb 2020

AlpineLinux: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/4329 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

-- TimothyLegge - 21 Feb 2020

As an FYI Email::Address::XS is a lot more available than it was notable exceptions for CentoOS and Redhat

https://repology.org/project/perl:email-address-xs/versions

-- TimothyLegge - 15 Apr 2020

Commenting is disabled while not logged in