| msg150527 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2012-01-03 20:24 |
| All proposed fixes for a randomized hashing function raise and fall with a good random number generator to feed the random seed. The seed must be created very early in the startup phase of the interpreter, preferable before the basic types are initialized. CPython already have multiple sources for random data (win32_urandom in Modules/posixmodule.c, urandom in Lib/os.py, Mersenne twister in Modules/_randommodule.c). However we can't use them because they are wrapped inside Python modules which require infrastructure like initialized base types. Discussion at http://mail.python.org/pipermail/python-dev/2012-January/115263.html My proposed changes are implemented in my feature fork but not yet well tested. Windows build files needs modification, too. |
|
|
| msg150528 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-01-03 20:28 |
| (for the record, you can use the "create patch" button which creates a reviewable diff) |
|
|
| msg150545 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-01-03 22:17 |
| I disagree with that approach, basically because I disagree that we need a C implementation of MT. Platforms that don't provide /dev/urandom will just have to be less secure. Using the current time (in milliseconds if available) plus the current pid ought to be good enough as a random seed. |
|
|
| msg150549 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2012-01-03 22:37 |
| We already have a C implementation of MT in Modules/_randommodule.c. I just suggest that we move the implementation to a place, where we can use it as seed. |
|
|
| msg150594 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2012-01-04 07:30 |
| Why is this listed as a release blocker? It is questionable whether it should be done at all? It is a very aggressive change. |
|
|
| msg150598 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2012-01-04 09:29 |
| Release blocker: I was following the example in #13703. A RNG (PRNG or CSPRNG) is required for randomized hashing function. The patch contains more than just the RNG changes. Only Include/pyrandom.h, Modules/_randommodule.c, Modules/posixmodule.c, Python/hash.c and parts of Makefile.pre.in are relevant for this tracker item. Sorry for the inconvenience! |
|
|
| msg150612 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2012-01-04 15:02 |
| On Jan 04, 2012, at 07:30 AM, Raymond Hettinger wrote: >Why is this listed as a release blocker? It is questionable whether it >should be done at all? It is a very aggressive change. It's a release blocker so that the issue won't get ignored before the next release. That doesn't necessarily mean it must be fixed. |
|
|
| msg154899 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2012-03-04 15:00 |
| Demoting from release blocker since the hash collision issue got remedied differently. If this is not needed anymore, please close. |
|
|
| msg154904 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2012-03-04 18:55 |
| Yes, this ticket can be closed unless there is an interest to include the PRNG in the core. |
|
|
| msg154906 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-03-04 19:39 |
| This is indeed out-of-date. |
|
|