[issue13703] Hash collision security issue
report at bugs.python.org
Wed Jan 25 20:13:09 CET 2012
Antoine Pitrou <pitrou at free.fr> added the comment:
> Jim Jewett <jimjjewett at gmail.com> added the comment:
> On Wed, Jan 25, 2012 at 1:05 PM, Antoine Pitrou <pitrou at 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):
That may be slowing down things quite a bit. It looks correct though.
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list