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

[Nathaniel Smith]

On Thu, Jun 9, 2016 at 6:53 PM, Barry Warsaw <barry at python.org> wrote:
> On Jun 09, 2016, at 03:22 PM, Larry Hastings wrote:
>
>>On 06/09/2016 08:52 AM, Guido van Rossum wrote:
>>> That leaves direct calls to os.urandom(). I don't think this should > block either.
>>
>>Then it's you and me against the rest of the world ;-)
>
> FWIW, I agree with you and Guido.  I'm also not opposed to adding a more
> direct exposure of getrandom(), but in Python 3.6 only.  Like it or not,
> that's the right approach for our backward compatibility policies.

I suspect the crypto folks would be okay with pushing this back to
3.6, so long as the final resolution is that os.urandom remains the
standard interface for, as the docstring says, "Return[ing] a string
of n random bytes suitable for cryptographic use" using the
OS-recommended method, and they don't have to go change all their
code. After all, 3.4 and 2.7 will still have this subtle brokenness
for some time.

But I'm a little uncertain what you think would need to happen to
satisfy the backwards compatibility policies. If we can change it in
3.6 without having a warning in 3.5, then presumably we can also
change it in 3.5 without a warning in 3.4, which is what already
happened accidentally :-).

Would it be acceptable for 3.5.2 to start raising a warning "urandom
returning non-random bytes -- in 3.6 this will be an error", and then
make it an error in 3.6?

(And it would probably be good even in the long run to issue a
prominent warning if hash seeding fails.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org