Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. -- Regards, Benjamin
1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
I think this is a good compromise given the widely varying assessments of the issue. Regards, Martin
Benjamin Peterson wrote:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
Do you have the expectation that it will become on by default in some future release? -- Steven
2012/1/27 Steven D'Aprano <steve@pearwood.info>:
Benjamin Peterson wrote:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
Do you have the expectation that it will become on by default in some future release?
Yes, 3.3. The solution in 3.3 could even be one of the more sophisticated proposals we have today. -- Regards, Benjamin
On Fri, Jan 27, 2012 at 5:19 PM, Benjamin Peterson <benjamin@python.org> wrote:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
Okay, good call! -- --Guido van Rossum (python.org/~guido)
Am 28.01.2012 02:19, schrieb Benjamin Peterson:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
FWIW, the same will be done for 3.2. Georg
On Fri, Jan 27, 2012 at 6:33 PM, Benjamin Peterson <benjamin@python.org> wrote:
2012/1/27 Steven D'Aprano <steve@pearwood.info>:
Benjamin Peterson wrote:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
Do you have the expectation that it will become on by default in some future release?
Yes, 3.3. The solution in 3.3 could even be one of the more sophisticated proposals we have today.
Yay! Thanks for the decision Release Managers! -gps
On Fri, Jan 27, 2012 at 21:33, Benjamin Peterson <benjamin@python.org>wrote:
2012/1/27 Steven D'Aprano <steve@pearwood.info>:
Benjamin Peterson wrote:
Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability.
Great!
Do you have the expectation that it will become on by default in some
future
release?
Yes, 3.3. The solution in 3.3 could even be one of the more sophisticated proposals we have today.
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).
On Tue, Jan 31, 2012 at 3:03 AM, Brett Cannon <brett@python.org> 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).
On-by-default should be enough to cover that. Just as we allow people to force the random seed to reproduce particular sequences, there's value in being able to increase determinism in cases where the collision attack isn't a concern. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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
participants (10)
-
Barry Warsaw
-
Benjamin Peterson
-
Brett Cannon
-
Georg Brandl
-
Gregory P. Smith
-
Guido van Rossum
-
Jim J. Jewett
-
martin@v.loewis.de
-
Nick Coghlan
-
Steven D'Aprano