On 23 June 2016 at 18:47, Donald Stufft <don...@stufft.io> wrote: >> Standing against that is the argument that we wouldn't want the >> recommended idiom for using the secrets module to become the >> boilerplatish: >> >> import secrets >> secrets.wait_for_system_rng() >> > > Alternative here is to just make every function in secrets ensure it waits > for the system RNG, possibly by calling said wait_for_system_rng() function > if we still think it’s worth it to make it a public API with a global that > gets set once it’s been recorded once.
While we could definitely do that, I think the complexity of it would push me towards Victor's "just make os.urandom potentially blocking at system startup" proposal. If 522 is going to make sense, I think it needs to be framed in a way that makes blocking for the system RNG clearly an at-most-once-per-process activity. > The fallback to /dev/random may be a bad idea though, even if it’s only done > once per process, I can imagine a case where someone is using emphereal > processes so they end up hitting /dev/random regularly. Using getrandom() for > this is fine because that state is per machine not per process, but the > Python level “has RNG been initialized” is per process so that could end up > with an unintended side effect of hitting /dev/random a lot. That's the bug that lead to me changing the suggested code to try os.urandom() once first, before falling back to blocking on /dev/random. Once the system RNG is ready, that first call will always succeed, no matter how many new processes you start. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
