On Wed, Dec 16, 2009 at 4:16 PM, Michael G Schwern <schw...@pobox.com> wrote: > I am, quite frankly, appalled at the response I've gotten to this report. > > No, this is not something the user should be guarding against. No, > documenting it does not make it go away. No, you shouldn't put an arbitrary > upper bound in. No, I should not have been using UTC. That is all > accepting low-quality. We don't do that in Perl. > > This isn't just an annoyance, its a wide spread security hole triggered by > totally innocent use. Its like finding out my doorbell will cause my house > to explode if somebody buzzes too long. I do not want to program in an > environment where the assumption is that everything is dangerous. This > isn't even a problem one should imagine encountering. > > The reaction I was expecting was more along the lines of "oh fuck, that's > really bad, let's figure out how to fix this". Yes, its ok to report a > problem without a ready solution. Instead, I'm told its documented and to > cough up a patch. > > This is not a simple problem to solve. I'm not even sure what the efficient > DST algorithm is, though I'm looking for it. I've looked into the > DateTime::TimeZone code before and this is not going to be a simple patch. > I'm willing to try and fix it, but not if the DateTime folks, the folks who > know the code, are reacting with something between lethargy and hostility. > It going to be hard enough without dragging everyone along. > > Give me something to work with here. Some insight into what and why > DateTime is doing what its doing. Is there a reason that DST info has to be > generated linearly? Would it be difficult to hold off on generating time > zone info until its needed? Are there instructions somewhere for dealing > with the Olsen database? SOME sort of discussion about how to solve the > problem rather than the ways to paper over it. >
I don't want to be insensitive, but I think this response is a touch melodramatic. First, Perl has plenty of dangerous behaviors. CGI's param(...) returning a list can cause a lot of problems and exploits if a user isn't careful and sanitize their input properly. To claim that "Perl doesn't do that" doesn't make it true. Programming is hard. Second, I think you grossly misconstrued the responses to this. I think everybody suggesting things in the thread did it with the mentality of an intermediate fix rather than a long term one. Very few people are comfortable with the internals of DateTime to offer up proper solutions. Third, you aren't going to get an "oh fuck" reaction out of a problem that is documented any more than you would expect Congress recalling all vehicles because if you hold the accelerator down you could crash into a brickwall. Analogies suck, lets not use them. The point is that raising a known issue and expecting something different than, "Yes, we know about it what are other ways to handle it" seems a little on the unreasonable size. On a constructive note, DateTime::TimeZone has Olsen timezone information. I had no idea that it didn't suffer the same problem (like I said, I don't have a clue about the Internals, and I just extrapolated that to "Very few people"... busted). I think that at the very least an *intermediate* fix would be to update the pod warning to be more prominent and a mention that Olsen tz files do not suffer the same consequences. Thanks, -J PS., Schwern, you're the man. If you can't do it, who can!? I still have your tea, btw (probably long stale now). If you can get this fixed, I'll throw in a pitcher of beer with it.
