2016-06-24 2:33 GMT+02:00 Nick Coghlan <ncogh...@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 _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
