[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:

 PYRANDOMHASH=1
   enable randomized hashing function

 PYRANDOMHASH=/path/to/seed
   enable randomized hashing function and read seed from 'seed'

 PYRANDOMHASH=0
   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.

Christian


More information about the Python-Dev mailing list