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

Christian Heimes lists at cheimes.de
Thu Jan 5 22:40:58 CET 2012

Am 05.01.2012 21:45, schrieb Barry Warsaw:
> This sounds like a reasonable compromise for all stable Python releases.  It
> can be turned on by default for Python 3.3.  If you also make the default
> setting easy to change (i.e. parameterized in one place), then distros can
> make their own decision about the default, although I'd argue for the above
> default approach for Debian/Ubuntu.

Hey Barry, stop stealing my ideas! :) I've argued for these default
settings for days.

ver	delivery	randomized hashing
2.3	patch		disabled by default
2.4	patch		disabled
2.5	patch		disabled
2.6	release		disabled
2.7	release		disabled
3.0	ignore?		disabled
3.1	release		disabled
3.2	release		disabled
3.3	n/a yet		enabled by default

2.3 to 2.5 are still used in production (RHEL, Ubuntu LTS). Guido has
stated that he needs a patch for 2.4, too. I think we may safely ignore
Python 3.0. Nobody should use Python 3.0 on a production system.

I've suggested the env var PYRANDOMHASH. It's easy to set env vars in
Apache. For example Debian/Ubuntu has /etc/apache2/envvars.

Settings for PYRANDOMHASH:

   enable randomized hashing function

   enable randomized hashing function and read seed from 'seed'

   disable randomed hashing function

Since there isn't an easy way to set env vars in a shebang line since
something like

  #!/usr/bin/env PYRANDOMHASH=1 python2.7

doesn't work, we could come up with a solution the shebang.

IMHO the setting for the default setting should be a compile time
option. It's reasonable easy to extend the configure script to support
--enable-randomhash / --disable-randomhash. The MS VC build scripts can
grow a flag, too.

I still think that the topic needs a PEP. A couple of days ago I started
with a PEP. But Guido told me that he doesn't see a point in a PEP
because he prefers a small and quick solution, so I stopped working on
it. However the arguments, worries and ideas in this enormous topic have
repeated over and over. We know from experience that a PEP is a great
way to explain the how, what and why of the change as well as the paths
we didn't take.


More information about the Python-Dev mailing list