[Python-Dev] Status of the fix for the hash collision vulnerability
Guido van Rossum
guido at python.org
Sun Jan 15 17:10:54 CET 2012
On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Terry Reedy, 14.01.2012 06:43:
> > On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
> >> It is perfectly okay to break existing users who had anything depending
> >> on ordering of internal hash tables. Their code was already broken.
> > Given that the doc says "Return the hash value of the object", I do not
> > think we should be so hard-nosed. The above clearly implies that there is
> > such a thing as *the* Python hash value for an object. And indeed, that
> > been true across many versions. If we had written "Return a hash value
> > the object, which can vary from run to run", the case would be different.
> Just a side note, but I don't think hash() is the right place to document
You mean we shouldn't document that the hash() of a string will vary per
> Hashing is a protocol in Python, just like indexing or iteration.
> Nothing keeps an object from changing its hash value due to modification,
Eh? There's a huge body of cultural awareness that only immutable objects
should define a hash, implying that the hash remains constant during the
> and that would even be valid in the face of the usual dict lookup
> invariants if changes are only applied while the object is not referenced
> by any dict.
And how would you know it isn't?
> So the guarantees do not depend on the function hash() and may
> be even weaker than your above statement.
There are no actual guarantees for hash(), but lots of rules for
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev