[Python-Dev] plugging the hash attack

Jim J. Jewett jimjjewett at gmail.com
Thu Feb 16 22:01:45 CET 2012



In http://mail.python.org/pipermail/python-dev/2012-January/116003.html


>> > Benjamin Peterson wrote:
>> >> 2. It will be off by default in stable releases ... This will
>> >> prevent code breakage ...

>> 2012/1/27 Steven D'Aprano <steve at pearwood.info>:
>> > ... it will become on by default in some future release?

> On Fri, Jan 27, 2012, Benjamin Peterson <benjamin at python.org> wrote:
>> Yes, 3.3. The solution in 3.3 could even be one of the more
>> sophisticated proposals we have today.

Brett Cannon (Mon Jan 30) wrote:

> I think that would be good. And I would  even argue we remove support for
> turning it off to force people to no longer lean on dict ordering as a
> crutch (in 3.3 obviously).

Turning it on by default is fine.

Removing the ability to turn it off is bad.

If regression tests fail with python 3, the easiest thing to do is just
not to migrate to python 3.  Some decisions (certainly around unittest,
but I think even around hash codes) were settled precisely because tests
shouldn't break unless the functionality has really changed.  Python 3
isn't yet so dominant as to change that tradeoff.

I would go so far as to add an extra step in the porting recommendations;
before porting to python 3.x, run your test suite several times with
hash randomization turned on; any failures at this point are relying on
formally undefined behavior and should be fixed, but can *probably* be
fixed just by wrapping the results in sorted.

(I would offer a patch to the porting-to-py3 recommendation, except that
I couldn't find any not associated specifically with 3.0)

-jJ

-- 

If there are still threading problems with my replies, please 
email me with details, so that I can try to resolve them.  -jJ



More information about the Python-Dev mailing list