[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