2016-06-24 2:33 GMT+02:00 Nick Coghlan <ncoghlan@gmail.com>:
3. Switch to reading ``/dev/urandom`` directly (non-security sensitive)
It is what I propose for the random.Random constructor when the random module is imported.
Again, the question is if there is a real use case for it. And if yes, if the use case common enough to justify the change?
The extreme case is that all applications using os.urandom() would need to be modifiy to add a try/except BlockingIOError. I only exagerate to try to understand the impact of your PEP. I only that only a few applications will use such try/except in practice.
That's where the idea of also adding secrets.wait_for_system_rng() comes, rather than having to wrap every library call in a try/except block (or risk having those APIs become blocking ones such that async developers feel obliged to call them in a separate thread)
I expect that secrets.wait_for_system_rng() will be implemented as consuming at least 1 byte of entropy, to check if urandom is initialized, right? I'm not a big fan of this API: os.urandom() never blocks, secrets.wait_for_system_rng() helper. If you say that some users need to call secrets.wait_for_system_rng() first, for me there is an use case for blocking urandom. So I would expect a blocking urandom function in the os module directly. By the way, it would avoid "wasting" 1 random byte of entropy. Victor