On 22 June 2016 at 19:29, Guido van Rossum <[email protected]> wrote: > On Wed, Jun 22, 2016 at 7:18 PM, Donald Stufft <[email protected]> wrote: >> Once, only after boot. On most (all?) modern Linux systems there’s even >> part of the boot process that attempts to seed the CSPRNG using random >> values stored during a previous boot to shorten the time window between when >> it’s ready and when it’s not yet initialized. However, once it is >> initialized it will never block (or EAGAIN) again. > > Then shouldn't it be the responsibility of the boot sequence rather than of > the Python stdlib to wait for that event? IIUC that's what OS X does (I > think someone described that it even kernel-panics when it can't enter the > "good" state).
I spent some time browsing the (mostly-but-not-all public) results of https://bugzilla.redhat.com/buglist.cgi?quicksearch=getrandom today, and unfortunately that backed up the results of Ted Ts'o's "what if /dev/urandom blocked on Linux startup?" experiments [1]. That is, Linux has the same problem at the distro level that we do at the language runtime level: the historically permissive behaviour means that Linux has existing use cases where it's legitimate to start the init process without waiting for the kernel CSPRNG to be seeded, so distros can't currently unilaterally prevent the entire OS from starting just because that subsystem isn't ready yet. We have a significant advantage that the kernel and distro devs don't enjoy though, which is a *much* nicer mechanism for runtime error reporting (in the form of exceptions and tracebacks) - by taking advantage of that, I believe we can significantly improve the default behaviour, while also writing a fairly straightforward "if you get this exception when running on Python 3.6, assess your application's needs, then apply one of these remedies" note for the Python 3.6 porting guide. Regards, Nick. [1] https://mail.python.org/pipermail/python-dev/2016-June/145146.html -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Security-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/security-sig
