hash randomization in 3.3
Hello, Shouldn't it be enabled by default in 3.3? It's currently disabled. $ ./python -c "print(hash('aa'))" 12416074593111936 [44297 refs] $ ./python -c "print(hash('aa'))" 12416074593111936 [44297 refs] Thanks Antoine.
On Tue, 21 Feb 2012 14:58:41 -0500 Benjamin Peterson <benjamin@python.org> wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Should you be able to disable it?
PYTHONHASHSEED=0 should disable it. Do we also need a command-line option? Regards Antoine.
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
On Tue, 21 Feb 2012 14:58:41 -0500 Benjamin Peterson <benjamin@python.org> wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Should you be able to disable it?
PYTHONHASHSEED=0 should disable it. Do we also need a command-line option?
I don't think so. I was just wondering if we should force people to use it. -- Regards, Benjamin
Am 21.02.2012 20:59, schrieb Antoine Pitrou:
On Tue, 21 Feb 2012 14:58:41 -0500 Benjamin Peterson <benjamin@python.org> wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Should you be able to disable it?
PYTHONHASHSEED=0 should disable it. Do we also need a command-line option?
On the contrary. PYTHONHASHSEED should go in 3.3, as should any facility to disable or otherwise fix the seed. Regards, martin
On Tue, 21 Feb 2012 22:51:48 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 21.02.2012 20:59, schrieb Antoine Pitrou:
On Tue, 21 Feb 2012 14:58:41 -0500 Benjamin Peterson <benjamin@python.org> wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Should you be able to disable it?
PYTHONHASHSEED=0 should disable it. Do we also need a command-line option?
On the contrary. PYTHONHASHSEED should go in 3.3, as should any facility to disable or otherwise fix the seed.
Being able to reproduce exact output is useful to chase sporadic test failures (as with the --randseed option to regrtest). Regards Antoine.
On Wed, Feb 22, 2012 at 8:07 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 21 Feb 2012 22:51:48 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
On the contrary. PYTHONHASHSEED should go in 3.3, as should any facility to disable or otherwise fix the seed.
Being able to reproduce exact output is useful to chase sporadic test failures (as with the --randseed option to regrtest).
I'm with Antoine here - being able to force a particular seed still matters for testing purposes. However, the documentation of the option may need to be updated for 3.3 to emphasise that it should only be used to reproduce sporadic failures. Using it to work around applications that can't cope with randomised hashes would be rather ill-advised. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I'm with Antoine here - being able to force a particular seed still matters for testing purposes. However, the documentation of the option may need to be updated for 3.3 to emphasise that it should only be used to reproduce sporadic failures. Using it to work around applications that can't cope with randomised hashes would be rather ill-advised.
In the tracker, someone proposed that the option is necessary to synchronize the seed across processes in a cluster. I'm sure people will use it for that if they can. Regards, Martin
On Wed, Feb 22, 2012 at 3:20 PM, <martin@v.loewis.de> wrote:
I'm with Antoine here - being able to force a particular seed still matters for testing purposes. However, the documentation of the option may need to be updated for 3.3 to emphasise that it should only be used to reproduce sporadic failures. Using it to work around applications that can't cope with randomised hashes would be rather ill-advised.
In the tracker, someone proposed that the option is necessary to synchronize the seed across processes in a cluster. I'm sure people will use it for that if they can.
Yeah, that use case sounds reasonable, too. Another example is that, even within a machine, if two processes are using shared memory rather than serialised IPC, synchronising the hashes may be necessary. The key point is that there *are* valid use cases for forcing a particular seed, so we shouldn't take that ability away. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2/22/2012 1:57 AM, Nick Coghlan wrote:
In the tracker, someone proposed that the option is necessary to synchronize the seed across processes in a cluster. I'm sure people will use it for that if they can.
Yeah, that use case sounds reasonable, too. Another example is that, even within a machine, if two processes are using shared memory rather than serialised IPC, synchronising the hashes may be necessary. The key point is that there *are* valid use cases for forcing a particular seed, so we shouldn't take that ability away.
When we document the option to set the seed, we could mention that synchronization of processes that share data is the main intended use. -- Terry Jan Reedy
On Tue, Feb 21, 2012 at 15:05, Barry Warsaw <barry@python.org> wrote:
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Yes.
Should you be able to disable it?
No, but you should be able to provide a seed.
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security in that providing some seed secures them instead of just making it a tad harder for the attack. And it won't help with keeping compatibility with Python 2.7 installations that don't have randomization turned on by default. If we are going to allow people to turn this off then it should be basically the inverse of the default under Python 2.7 and no more.
On 2012-02-21, at 21:24 , Brett Cannon wrote:
On Tue, Feb 21, 2012 at 15:05, Barry Warsaw <barry@python.org> wrote:
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Yes.
Should you be able to disable it?
No, but you should be able to provide a seed.
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security in that providing some seed secures them instead of just making it a tad harder for the attack.
I might have misunderstood something, but wouldn't providing a seed always make it *easier* for the attacker, compared to a randomized hash?
On Tue, Feb 21, 2012 at 15:58, Xavier Morel <python-dev@masklinn.net> wrote:
On 2012-02-21, at 21:24 , Brett Cannon wrote:
On Tue, Feb 21, 2012 at 15:05, Barry Warsaw <barry@python.org> wrote:
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Yes.
Should you be able to disable it?
No, but you should be able to provide a seed.
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security in that providing some seed secures them instead of just making it a tad harder for the attack.
I might have misunderstood something, but wouldn't providing a seed always make it *easier* for the attacker, compared to a randomized hash?
Yes, that was what I was trying to convey.
On Feb 21, 2012, at 09:58 PM, Xavier Morel wrote:
On 2012-02-21, at 21:24 , Brett Cannon wrote:
On Tue, Feb 21, 2012 at 15:05, Barry Warsaw <barry@python.org> wrote:
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote:
2012/2/21 Antoine Pitrou <solipsis@pitrou.net>:
Hello,
Shouldn't it be enabled by default in 3.3?
Yes.
Should you be able to disable it?
No, but you should be able to provide a seed.
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security in that providing some seed secures them instead of just making it a tad harder for the attack.
I might have misunderstood something, but wouldn't providing a seed always make it *easier* for the attacker, compared to a randomized hash?
I don't think so. You'd have to somehow coerce the sys.hash_seed out of the process. Not impossible perhaps, but unlikely unless the application isn't written well and leaks that information (which is not Python's fault). Plus, with randomization enabled, that won't help you much past the current invocation of Python. -Barry
Brett Cannon writes:
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security
I thought the point of providing the seed was for reproducability of tests and the like? As for "false sense", can't we document this and chalk up hubristic behavior to "consenting adults"?
On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
Brett Cannon writes:
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security
I thought the point of providing the seed was for reproducability of tests and the like?
As for "false sense", can't we document this and chalk up hubristic behavior to "consenting adults"?
+1 -Barry
On Wed, 22 Feb 2012 12:59:33 -0500 Barry Warsaw <barry@python.org> wrote:
On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote:
Brett Cannon writes:
I think that's inviting trouble if you can provide the seed. It leads to a false sense of security
I thought the point of providing the seed was for reproducability of tests and the like?
As for "false sense", can't we document this and chalk up hubristic behavior to "consenting adults"?
+1
How is it a "false sense of security" at all? It's the same as setting a private secret for e.g. session cookies in Web applications. As long as you don't leak the seed, it's (should be) secure. (the only hypothetical issue being with Victor's choice of an LCG pseudo-random generator to generate the secret from the seed) Regards Antoine.
Antoine Pitrou writes:
How is it a "false sense of security" at all? It's the same as setting a private secret for e.g. session cookies in Web applications. As long as you don't leak the seed, it's (should be) secure.
That's true. The problem is, the precondition that you won't leak the seed is all too often false. If a user takes advantage of the ability to set the seed, she can leak it, or a coworker (or a virus) can steal it from her source or keystroke logging, etc. And it's not the same, at least not for a highly secure application. In high-quality security, session keys are generated for each session (and changed frequently); the user doesn't know them (of course, he can always find out if he really wants to know, and sometimes that's necessary -- Hello, Debian OpenSSH maintainer!), and so can't leak them.
Should you be able to disable it?
No, but you should be able to provide a seed.
Why exactly is that? We should take an attitude that Python hash values are completely arbitrary and can change at any point without notice. The only strict requirement should be that hashing must be consistent with equality; everything else should be an implementation detail. With that attitude, supporting explicit seeds is counter-productive. Regards, Martin
participants (11)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Glenn Linderman -
martin＠v.loewis.de
-
Nick Coghlan -
Stephen J. Turnbull -
Terry Reedy -
Xavier Morel