Message 151966 - Python tracker (original) (raw)

Jim Jewett <jimjjewett@gmail.com> added the comment:

On Wed, Jan 25, 2012 at 1:05 PM, Antoine Pitrou <pitrou@free.fr> added the comment:

It looks like that approach will break any non-builtin type (in either C or Python) which can compare equal to bytes or str objects. If that's the case, then I think the likelihood of acceptance is close to zero.

(1) Isn't that true of any patch that changes hashing? (Thus the PYTHONHASHSEED=0 escape hatch.)

If a third-party type wants to compare equal to bytes or str objects, its hash method will usually end up calling hash() on the equivalent bytes/str object. That's especially true for Python types (I don't think anyone wants to re-implement a slow str-alike hash in pure Python).

(2) I think it would still work for the lookdict_string (or lookdict_unicode) case ... which is the normal case, and also where most vulnerabilities should appear.

It would probably still work indeed.

(3) If the alternate hash is needed for non-string keys, there is no perfect resolution, but I suppose you could get closer with

if obj == str(obj):
    newhash=hash(str(obj))

That may be slowing down things quite a bit. It looks correct though.