On Thu, Jun 9, 2016 at 6:53 PM, Barry Warsaw <ba...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
