[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
Martin Panter
vadmium+py at gmail.com
Fri Jun 10 01:11:02 EDT 2016
> 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.
On 9 June 2016 at 22:22, Larry Hastings <larry at hastings.org> wrote:
> Then it's you and me against the rest of the world ;-)
>
>
> Okay, it's decided: os.urandom() must be changed for 3.5.2 to never block on
> a getrandom() call. It's permissible to take advantage of
> getrandom(GRND_NONBLOCK), but if it returns EAGAIN we must read from
> /dev/urandom.
So assuming this is the “final” decision, where to from here? I think
the latest change by Colm and committed by Victor already implements
this decision:
https://hg.python.org/cpython/rev/9de508dc4837
Getrandom() is still called, but if it would block, we fall back to
trying the less-secure Linux /dev/urandom, or fail if /dev/urandom is
missing. The Python hash seed is still set using this code. And
os.urandom() calls this code. Random.seed() and SystemRandom still use
os.urandom(), as documented.
So I suggest we close the original mega bug thread
<https://bugs.python.org/issue26839> as fixed. Unless people think
they can change Larry or Guido’s mind, we should focus further
discussion on any changes for 3.6.
More information about the Python-Dev
mailing list