> 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.

>  * accept Victor's existing changeset without my nonblocking_urandom_noraise patch, which makes _PyOS_URandom nonblocking in all Linux cases.
>  * resolve as above (both Victor's and my patches), and require that applications be modified to work correctly
>  * require modifications to hashlib.py and random.py to use nonblocking sources and/or raise exceptions accordingly.

Of these, I think random.py should just not use a CSPRNG, it's not required for it so there's no reason to do it. I don't think there's actually any problem with hashlib, I don't see any use of random in it.


> I would be interested in PSRT's assessment of an actual attack on a predictable hash secret 

For something like systemd-crontab-generator, basically nothing-- for anything short lived or which does not provide a means for arbitrary users to put data into a dictionary. IOW, it's largely persistent network services.