[Python-Dev] Hash collision security issue (now public)

[Antoine Pitrou]

On Thu, 5 Jan 2012 19:34:13 +0200
Maciej Fijalkowski <fijall at gmail.com> wrote:
> 
> Just to make things clear - stdlib itself has 1/64 of tests relying on
> dict order. Changing dict order in *older* pythons will break
> everyone's tests and some peoples code.

Breaking tests is not a problem: they are typically not run by
production code and so people can take the time to fix them.

Breaking other code is a problem if it is legitimate. Relying on dict
ordering is totally wrong and I don't think we should care about such
cases. The only issue is when relying on hash() being stable accross
runs. But hashing already varies from build to build (32-bit vs.
64-bit) and I think that anyone seriously relying on it should already
have been bitten.

> Making this new 2.6.x release
> would mean that people using new python 2.6 would have to upgrade an
> unspecified amount of their python packages, that does not sound very
> cool.

How about 2.7? Do you think it should also remain untouched?
I am ok for leaving 2.6 alone (that's Barry's call anyway) but 2.7 is
another matter - should people migrate to 3.x to get the security fix?

As for 3.2, it should certainly get the fix IMO. There are not many
Python 3 legacy applications relying on hash() stability, I think.

> Also consider that new 2.6.x would go as a security fix to old
> ubuntu, but all other packages won't, because they'll not contain
> security fixes.

Ubuntu can decide *not* to ship the fix if they prefer it like that.
Their policies and decisions, though, should not taint ours.

Regards

Antoine.