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

Reply via email to