On Thursday 18 January 2018 18:16:44 gregor herrmann wrote: > On Thu, 18 Jan 2018 18:10:38 +0100, Pali Rohár wrote: > > > > Thinking about upstream, I had another idea: If Email-Address is > > > unmaintained on the CPAN, you could take it over (request co-maint) > > > and then > > > - change Email::Address to a wrapper around Email::Address::XS; > > > - or remove the Email-Address distro and move the Email::Address > > > module, again changed to a wrapper, into the Email-Address-XS > > > distribution; > > > - or, maybe least controversial, improve Email::Address to load > > > Email::Address::XS if it's installed. In that case we could in > > > Debian just add a dependency on libemail-address-xs-perl to > > > libemail-address-perl. > > > > I had a discussion about Email::Address module and decision was to not > > do such things as Email::Address is pure Perl module and > > Email::Address::XS needs C compiler. There are lot of Perl systems where > > C compiler is not available and there only pure Perl modules can be > > installed/loaded. > > I totally see this point; that's why I added my third proposal above > and marked it as least controversial ("use ::XS if it is available"). > This would fix the issue in Debian, because here we can guarantee it > by a dependency, and it would at least improve the situation for > parts of rest of the world (the part which has a C compiler).
This does not fix the issue completely. Email::Address module exports "vulnerable" regexes, see: https://metacpan.org/source/RJBS/Email-Address-1.908/lib/Email/Address.pm#L126 And these regexes are not provided by Email::Address::XS module (as XS module parses email by own sequential parser). So it is better to not load Email::Address at all when application is known to work correctly with Email::Address::XS to prevent usage of insecure regexes. -- Pali Rohár pali.ro...@gmail.com