Larry -

I see at least two issues here, although they are related:

* blocking initialization of the hash secret. This occurs regardless of script contents; at present Python simply can't be used at all in low-entropy situations. I feel that this issue is a release blocker.

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


* blocking random reads during import hashlib or import random. This is more complex, as we need to take developer intentions into account. I do *not* think that these are release blockers as there are reasonably easy workarounds, however the fact remains that there has been a regression in Python's behavior on Linux.

Possible resolutions:

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

I see these largely as policy decisions rather than technical ones. The security implications of the first issue are fairly small (I would be interested in PSRT's assessment of an actual attack on a predictable hash secret); of the second issue rather larger and probably unquantifiable.