I'd say lets wait a bit and see what the upstream does.

(In reply to Sander Lepik from comment #1)
> I'd say lets wait a bit and see what the upstream does.

MITRE's response (with CVE assignment) supports waiting:
http://openwall.com/lists/oss-security/2015/10/02/13

Summary: perl-Email-Address possible DoS partially fixed in 1.908 => perl-Email-Address possible DoS (CVE-2015-7686)

i think we should update  perl-Email-Address  

wdyt ?

CC: (none) => mageia

(In reply to Nicolas Lécureuil from comment #3)
> i think we should update  perl-Email-Address  
> 
> wdyt ?

Yes.

uploaded in mga5 updates_testing 

SRPMS: perl-Email-Address-1.908.0-1.mga5

Assignee: mageia => qa-bugs

Advisory:
========================

Updated perl-Email-Address package fixes security vulnerability:

Pali Rohár discovered a possible DoS attack in any software which uses the
Email::Address Perl module for parsing string input to a list of email
addresses.

Note that this issue has only been partially mitigated in Email::Address itself.

References:
http://openwall.com/lists/oss-security/2015/09/27/1
http://lwn.net/Alerts/658813/
========================

Updated packages in core/updates_testing:
========================
perl-Email-Address-1.908.0-1.mga5

from perl-Email-Address-1.908.0-1.mga5.src.rpm

MGA5-32 on AcerD620 Xfce
No installation issues
Testing as per bug 13541
# grep 'my $quoted_string' /usr/lib/perl5/vendor_perl/*/Email/Address.pm
my $quoted_string  = qr/$cfws*"$qcontent*"$cfws*/;
and
$ perl testperlemail.pl
"Casey" <casey@localhost>

CC: (none) => herman.viaene
Whiteboard: advisory => advisory MGA5-32-OK

Looking at M5_64.

The first reference in the Advisory above states:
"By default Email::Address module, version v1.907 (and all before) try to understand nestable comments in input string with deep level 2."
 and:
"In attachment I'm sending example perl script which uses Email::Address module for parsing From header and example input... On my machine that script runs 5 seconds and it parse just four addresses."
Alas: "[ CONTENT OF TYPE application/x-perl SKIPPED ]"
Is there any way of getting at this PoC?
---
Wikipedia:
comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com.

Comments are allowed in the domain as well as in the local-part; for example, john.smith@(comment)example.com and john.smith@example.com(comment) are equivalent to john.smith@example.com.

A regular expression can be used to check for all of these criteria, except that of bracketed nested comments. [Guess (..(..)..) ]
---
 $ perldoc Email::Address      is helpful - also for methods:
The specification for an email address allows for infinitely nestable comments. That's nice in theory, but a little over done. By default this module allows for two (2) levels of nested comments.
---
Example of nested comment:
The following valid email address, for example, contains a total of three comments (the middle one being also a nested comment): 
 john(smith)@(my (domain))example.com(tld)
---
The source change is just from literal 2 to 1 (comment nesting level).
-our $COMMENT_NEST_LEVEL ||= 2;
+our $COMMENT_NEST_LEVEL ||= 1;

Being now better informed, I will attempt a little perl script for this.

CC: (none) => lewyssmith

Testing M5 x64

BEFORE update: perl-Email-Address-1.905.0-4.mga5
I battled in vain with Email::Address. Short of manually defining the elements of a composite e-mail address object e.g.
 my $address = Email::Address->new(undef, 'casey@local', '(Casey)');
[params are leading string, e-mail address, comments]
Using
 my @objs = Email::Address->parse($_);
to read them - yes, even several on a line - from STDIN worked; but I could *not* extract a single object from that array of objects. None of the perldoc examples for establishing a single object referred to the array as a source. And all the methods only work for a single $object...

However, I was able to show that any address with (un-nested comments) or (once (nested) comments) seemed to work, separating the input string into 3 elements: "prefix" (if present), raw <e-mail-address>, (Comments) concatenated - nested comments shown integrally, not separated out. The variation of comments in the 4 possible positions in the <address> field did not matter.

Correct, comments nested just once:
Input: "my name" <(c1 (c1a c1a2) c1b)e.maill@addr.ess(c3 (c3a) c32)>           
Output: "my name" <e.maill@addr.ess> (c1 (c1a c1a2) c1b) (c3 (c3a) c32) 

Incorrect, comments nested twice:
Input: "my name" <(c1 (c1a c1a2) c1b)e.maill@addr.ess(c3 (c3a (c3a1) c3b) c3b)>
Ouput: <e.maill@addr.ess> (c1 (c1a c1a2) c1b)

AFTER update to: perl-Email-Address-1.908.0-1.mga5
Basically, *any* nested comment now causes incorrect output. The effect of reducing that level.

Correct, no comment nesting:
Input: prefix<john(smith)@(my )example.com(tld)>
Output: "prefix" <john@example.com> (smith) (my ) (tld)
I/P  prefix name.name <(c1  c1b)e.maill@addr.ess(comment)> 
O/P "prefix name.name" <e.maill@addr.ess> (c1 c1b) (comment)

Incorrect with any comment nesting:
Input: "prefix name.name" <(c1 (c1a c1a2) c1b)e.maill@addr.ess(comment)>
Output: <e.maill@addr.ess> (comment)

This is a strange update, but it seems to do what it wants. OK.

Whiteboard: advisory MGA5-32-OK => advisory MGA5-32-OK MGA5-64-OK

Validated. Advisory already done.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0397.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED