>> 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 _______________________________________________ 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
