| Subject: | regression in date/time parsing and possible DoS on 64bits platforms |
We use Date::Manip to parse EXIF date formats. From the 50 million
photos in our system, we found over 200 variants, and D::M used to be
able to extract something meaningful from most of them, with the
following snippet:
my $exifdate = '2009:06:25 13:02:48-04:00';
$exifdate =~ s/\D//g;
print ParseDate($exifdate); # 2010090523:13:10
The new version 6 no longer parses these, which is unfortunate, but I
can certainly understand your desire for some sanity in your parsing
code. The big strength of Date::Manip used to be that I could throw any
user input at it, and most of the time I'd end up with a date/time the
user intended. I accept that that also means it could get it horribly
wrong sometimes...
But what is more severe in the current behavior with this input on a
64bits perl: it uses up all available memory building the cache, and
this can cause a denial of service.
I looked briefly under the debugger, and it keeps on calling
days_since_1BC() and adding entries to $self->{cache}. I assume this is
because under 64bits, the string '200906251302480400' is a valid
integer, and if you treat that as an epoch, it'll be quite far into the
future.
I apologise for not providing a patch, or a more detailed investigation
of the underlying issue. Being under time pressure, I chose to bundle an
older version of D::M with our app.