Hi, It seems to me that half the folk discussing this issue want a super-strong, resist-all-hypothetical-attacks hash with little regard to performance. The other half want no change or a change that will have no observable effect. (I may be exaggerating a little.) Can I propose the following, half-way proposal: 1. Since there is a published vulnerability, that we fix it with the most efficient solution proposed so far: http://bugs.python.org/file24143/random-2.patch 2. Decide which versions of Python this should be applied to. 3.3 seems a given, the other are open to debate. 3. If and only if (and I think this unlikely) the solution chosen is shown to be vulnerable to a more sophisticated attack then a new issue should be opened and dealt with separately. Cheers, Mark.
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