[Python-Dev] Hash collision security issue (now public) (original) (raw)
Christian Heimes lists at cheimes.de
Thu Jan 5 22:40:58 CET 2012
- Previous message: [Python-Dev] Hash collision security issue (now public)
- Next message: [Python-Dev] Hash collision security issue (now public)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Hash collision security issue (now public)
- Next message: [Python-Dev] Hash collision security issue (now public)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]