[Python-Dev] Status of the fix for the hash collision vulnerability

[Guido van Rossum]

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
> has
> > been true across many versions. If we had written "Return a hash value
> for
> > 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
> this.


You mean we shouldn't document that the hash() of a string will vary per
run?


> 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
object's lifetime.


> 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
well-behaved hashes.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120115/e2ef01e7/attachment.html>