[Python-Dev] Hash collision security issue (now public) (original) (raw)

David Malcolm dmalcolm at redhat.com
Thu Jan 5 21:52:15 CET 2012

On Thu, 2012-01-05 at 20:35 +0000, Paul Moore wrote:

On 5 January 2012 19:33, David Malcolm <dmalcolm at redhat.com> wrote: > 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 modpython/modwsgi 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.

Uh, surely no-one is suggesting backporting to "ancient" versions? I couldn't find the statement quickly on the python.org website (so this is via google), but isn't it true that 2.6 is in security-only mode and 2.5 and earlier will never get the fix? Having a source-only release for 2.6 means the fix is "off by default" in the sense that you can choose not to build it. Or add a #ifdef to the source if it really matters. Sorry, if I was unclear. I don't expect python-dev to do this backporting, but those of us who do maintain such ancient pythons via Linux distributions may want to do the backport for our users. My email was to note that it may make sense to pick more conservative defaults for such a scenario, as compared to 2.6 onwards.

[snip]

Hope this is helpful Dave

More information about the Python-Dev mailing list