[Security-sig] Take a decision for os.urandom() in Python 3.6

[Tim Peters]

[Guido]
> ...
> There is one thing that is still really unresolved for me, and that is
> a good understanding of how likely this feared event, "not having
> enough entropy" actually is, for environments where Python may
> actually be used. My main question is, can it occur in situations
> *other* than during very early startup? What's the answer for various
> platforms? Once I'm past this boot phase, can I safely assume
> os.urandom() will never block, or is there still a possibility for a
> system to run out of entropy later (say, by excessive calls to
> os.urandom(), possibly in another process)?

No such platforms have been identified in any of these messages, so
"no" is the answer - for now ;-)

Under the covers, all these things use _some_ crypto-strength but
deterministic PRNG.  So the only time they _may_ get in real trouble
is at startup, waiting to initialize the CSPRNG's state from "enough"
random noise (even then, sane environments save a file of gibberish
before shutdown to use to seed the CSPRNG "immediately" at the next
boot).  The best systems periodically mix fresh "entropy" into the
CSPRNG's state all along, but don't wait for it after initialization.

> ...
> But, assuming I am asked for a vote, my vote goes to Victor's PEP 524,
> making os.urandom() occasionally block even on Linux, and adding
> os.getrandom() on those platforms that have it.

+1 here :-)