On Thu, 2012-01-05 at 19:34 +0200, Maciej Fijalkowski wrote: > On Thu, Jan 5, 2012 at 3:39 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Thu, 5 Jan 2012 15:26:27 +1100 > > Andrew Bennetts <and...@bemusement.org> wrote: > >> > >> I don't think that's news either. > >> http://mail.python.org/pipermail/python-dev/2003-May/035907.html and > >> http://twistedmatrix.com/pipermail/twisted-python/2003-June/004339.html for > >> instance show that in 2003 it was clearly known to at least be likely to > >> be an > >> exploitable DoS in common code (a dict of HTTP headers or HTTP form keys). > >> > >> There was debate about whether it's the language's responsibility to > >> mitigate > >> the problem or if apps should use safer designs for handling untrusted > >> input > >> (e.g. limit the number of keys input is allowed to create, or use something > >> other than dicts), and debate about just how practical an effective exploit > >> would be. But I think it was understood to be a real concern 8 years ago, > >> so > >> not exactly sudden. > > > > That's not news indeed, but that doesn't make it less of a problem, > > especially now that the issue has been widely publicized through a > > conference and announcements on several widely-read Web sites. > > > > That said, only doing the security fix in 3.3 would have the nice side > > effect of pushing people towards Python 3, so perhaps I'm for it after > > all. > > > > Half-jokingly, > > > > Antoine.
> > Just to make things clear - stdlib itself has 1/64 of tests relying on > dict order. Changing dict order in *older* pythons will break > everyone's tests and some peoples code. Making this new 2.6.x release > would mean that people using new python 2.6 would have to upgrade an > unspecified amount of their python packages, that does not sound very > cool. Also consider that new 2.6.x would go as a security fix to old > ubuntu, but all other packages won't, because they'll not contain > security fixes. Just so you know We have similar issues in RHEL, with the Python versions going much further back (e.g. 2.3) When backporting the fix to ancient python versions, I'm inclined to turn the change *off* by default, requiring the change to be enabled via an environment variable: I want to avoid breaking existing code, even if such code is technically relying on non-guaranteed behavior. But we could potentially tweak mod_python/mod_wsgi so that it defaults to *on*. That way /usr/bin/python would default to the old behavior, but web apps would have some protection. Any such logic here also suggests the need for an attribute in the sys module so that you can verify the behavior. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
