[Python-Dev] Status of the fix for the hash collision vulnerability (original) (raw)

Victor Stinner victor.stinner at haypocalc.com
Wed Jan 18 00:25:23 CET 2012

I plan to commit my fix to Python 3.3 if it is accepted. Then write a simplified version to Python 3.2 and backport it to 3.1. I'm opposed to any change to the hash values of strings in maintenance releases, so I guess I'm opposed to your patch in principle.

If randomized hash cannot be turned on by default, an alternative is to switch them off by default, and add an option (command line option, environment variable, etc.) to enable it.

The vulnerability is public since one month, it is maybe time to fix it before it is widely exploited. I don't think there is any urgency. The vulnerability has been known for more than five years now. From creating a release to the point where the change actually arrives at end users, many months will pass.

In 2003, Python was not seen as vulnerable. Maybe because the hash function is different than Perl hash function, or because nobody tried to generate collisions. Today it is clear that Python is vulnerable (64 bits version is also affected), and it's really fast to generate collisions using the right algorithm.

Why is it so long to fix the vulnerability in Python, whereas it was fixed quickly in Ruby? (they chose to use a randomized hash)

Victor

More information about the Python-Dev mailing list