Dave Malcolm <dmalc...@redhat.com> added the comment: I arbitrarily started with 50, and then decided a power of two would be quicker when multiplying. There wasn't any rigorous analysis behind the choice of factor.
Though, as noted in msg151796, I've gone off this idea, since I think the "protection" creates additional avenues of attack. I think getting some kind of hash randomization patch into the hands of users ASAP is the way forward here (even if disabled by default). If we're going to support shipping backported versions of the hash randomization patch with the randomization disabled, did we decide on a way of enabling it? If not, then I propose that those who want to ship with it disabled by default standardize on (say): PYTHONHASHRANDOMIZATION as an environment variable: if set to nonzero, it enables hash randomization (reading the random seed as per the 3.3. patch, and respecting the PYTHONHASHSEED variable if that's also set). If set to zero or not present, hash randomization is disabled. Does that sound sane? (we can't use PYTHONHASHSEED for this, since if a number is given, that means "use this number", right?) FWIW, I favor hash randomization in 2.* for PyStringObject, PyUnicodeObject, PyBufferObject, and the 3 datetime classes in Modules/_datetimemodule.c (see the implementation of generic_hash in that file), but to not do it for the numeric types. Sorry; I only tried it on the python test suite (and on a set of reproducers for the DoS that I've written for RH's in-house test suite). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13703> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
