[Python-Dev] Hash collision security issue (now public)
solipsis at pitrou.net
Thu Jan 5 20:22:22 CET 2012
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
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.
More information about the Python-Dev