Christian Heimes added the comment: On 2016-06-07 19:36, Donald Stufft wrote: > > Donald Stufft added the comment: > >> Possible resolutions: >> * accept possible low-entropy initialization of the hash secret; using the >> patches supplied here by myself and Victor. >> * add a command-line flag to disable "strong" initialization of the hash >> secret (or revive the old -R flag). >> * simply require user-space workarounds like setting PYTHONHASHSEED > > I think either the first or second here are good solutions, the third is kind > of crummy on it's own because it's not always possible to pass in an > environment variable. Pairing the third with a CLI flag option might work out > nice though, perhaps a -XPYTHONHASHSEED=(random/int()) or something. Then > folks who are in early boot can easily just hardcode a hash seed, removing > the need to hit the entropy pools while still maintaining strong random for > everyone else. > > So I guess I would lean towards adding a CLI flag, but just allowing SipHash > to fall back to possibly bad randomness for it's initialization is OK.
I don't like the fact that applications can fall back to insecure RNG without user involvement or warning. Therefore I'm in favor of a command line argument that allows pyhash.c to fall back to a less secure RNG. System scripts must use the -I option (isolated mode without user-site dir and PY* env vars) anyway. The new option would enable less secure RNG as fallback and -I. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com