[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Martin Panter vadmium+py at gmail.com
Fri Jun 10 01:11:02 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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(GRNDNONBLOCK), 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.
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]