[issue13703] Hash collision security issue

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> I think you're right: it will stop matching it during lookup within such
> a dict, since the dict will be using the secondary hash for "abc", but
> hash() for the C instance.
> 
> It will still match outside of the dict, and within other dicts.
> 
> So yes, this would be a subtle semantic change when under attack.
> Bother.

Hmm, you're right, perhaps it's not as important as I thought.

By the way, have you run benchmarks on some of your patches?

> Is this discussion likely to reach a conclusion soon?  Would it be
> regarded as rude if I unilaterally ship something close to:
>   backport-of-hash-randomization-to-2.7-dmalcolm-2012-01-23-001.patch
> in RHEL/Fedora, so that my users have some protection they can enable if
> they get attacked?

I don't think Fedora shipping its own patches can be considered "rude"
by anyone else than its users. And deciding what is best for your users
is indeed your job as a distro maintainer, not python-dev's.

> As for python.org, who is empowered to make a decision here?  How can we
> move this forward?

I don't know. Guido is empowered if he wants to make a pronouncement.
Otherwise, we have the following data points:

- hash randomization is generally considered the cleanest solution
- hash randomization cannot be enabled by default in bugfix, let alone
security releases
- collision counting can mitigate some of the attacks, although it can
have weaknesses (see Frank's emails) and it comes with its own problems
(breaking the program "later on")

So I'd suggest the following course of action:
- ship and enable some form of collision counting on bugfix and security
releases
- ship and enable hash randomization in 3.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________