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

[Guido van Rossum]

Can we stop the discussion please? I have picked a winner. The loser
may not like it, but the discussion is OVER.

On Sun, Aug 7, 2016 at 9:33 AM, Donald Stufft <donald at stufft.io> wrote:
>
>> On Aug 7, 2016, at 12:28 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>> At this point we have concrete examples of the harm caused by blocking on os.urandom -- do we have any actual use-cases where it is hurtful to raise instead?
>
> The use cases there are basically any time it would have only blocked for say, half a second or so. It’s hard to point out a specific use case because  we’ve never had an error raising there, we’ve either just silently given them bad data because /dev/urandom wasn’t initialized or we blocked and they didn’t notice because it only blocked for a short time.
>
> I suspect that the “can block for a short time” will be the dominant case, because the system generally gets entropy quite quickly in most scenarios. The only time it can’t really is if Python is the only thing running early enough in the boot process *and* that thing is calling os.urandom. The problem we had that started this thread was SipHash initialization calling a blocking urandom by a script called by systemd prior to the point where systemd would attempt to reseed urandom from previous boots and prior to the point that systemd parallelizes the boot process.
>
> Basically any other time the time to block will be relatively short (and in fact, you see daemons like OpenSSH blocking on start up for similar reasons).
>
> —
> Donald Stufft
>
>
>



-- 
--Guido van Rossum (python.org/~guido)