[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Terry Reedy]

On 6/9/2016 9:48 AM, Doug Hellmann wrote:
>
>> On Jun 9, 2016, at 9:27 AM, Cory Benfield <cory at lukasa.co.uk>
>> wrote:

>> The problem here is that both definitions of ‘broken’ are unclear.
>> If we leave os.urandom() as it is, there is a small-but-nonzero
>> change that your program will hang, potentially indefinitely. If we
>> change it back, there is a small-but-nonzero chance your program
>> will generate you bad random numbers.
>>
>> If we assume, for a moment, that os.urandom() doesn’t get called
>> during Python startup (that is that we adopt Christian’s approach
>> to deal with random and SipHash as separate concerns), what we’ve
>> boiled down to is: your application called os.urandom() so early
>> that you’ve got weak random numbers, does it hang or proceed? Those
>> are literally our two options.
>
> I agree those are the two options. I want the application developer
> to make the choice, not us.

I think the 'new API' should be a parameter, not a new function. With 
just two choices, 'wait' = True/False  could work.  If 'raise an 
exception' were added, then
'action (when good bits are not immediately available' =
'return (best possible)' or
'wait (until have good bits)' or
'raise (CryptBitsNotAvailable)'

In either case, there would then be the question of whether the default 
should match 3.5.0/1 or 3.4 and before.

-- 
Terry Jan Reedy