(original) (raw)
FWIW the quick change i pastebin'ed is basically covered by the change already under review in�http://bugs.python.org/review/13704/show. �I've made my comments and suggestions there.
I looked into Modules/expat/xmlparse.c and it has an odd copy of the old string hash algorithm entirely for its own internal use and its own internal hash table implementations. �That module is likely vulnerable to creatively crafted documents for the same reason. �With 13704 and the public API it provides to get the random hash seed, that module could simply be updated to use that in its own hash implementation.
As for when to enable it or not, I unfortunately have to agree, despite my wild desires we can't turn on the hash randomization change by default in anything prior to 3.3.
-gps
On Sat, Jan 14, 2012 at 11:17 AM, Gregory P. Smith <greg@krypto.org> wrote:
My patch example does change the bytes object hash as well as Unicode.
On Jan 13, 2012 7:46 PM, <martin@v.loewis.de> wrote:What an implementation looks like:
�http://pastebin.com/9ydETTag
some stuff to be filled in, but this is all that is really required.
I think this statement (and the patch) is wrong. You also need to change
the byte string hashing, at least for 2.x. This I consider the biggest
flaw in that approach - other people may have written string-like objects
which continue to compare equal to a string but now hash different.
Regards,
Martin
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/greg%40krypto.org