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

Antoine Pitrou 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 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.

More information about the Python-Dev mailing list