[Security-sig] PEP 522: Allow BlockingIOError in security sensitive APIs on Linux

[Victor Stinner]

2016-06-24 2:33 GMT+02:00 Nick Coghlan <ncoghlan at 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