[Python-Dev] Status of the fix for the hash collision vulnerability

[martin at v.loewis.de]

> 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