> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4