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

martin at v.loewis.de martin at v.loewis.de
Wed Jan 18 01:37:49 CET 2012

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.

That won't really fix the problem. If people install a new release because it fixes a vulnerability, it better does so.

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.

There is the common vulnerability to the threat of confusing threats with vulnerabilities [1]. Python was vulnerable all the time, and nobody claimed otherwise. It's just that nobody saw it as a threat. I still don't see it as a practical threat, as there are many ways that people use in practice to protect against this threat already. But I understand that others feel threatened now.

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)

Because the risk of breakage for Python is much higher than it is for Ruby.

Regards, Martin

[1] http://jps.anl.gov/Volume4_iss2/Paper3-RGJohnston.pdf

More information about the Python-Dev mailing list