On 23 June 2016 at 18:47, Donald Stufft <donald@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 | ncoghlan@gmail.com | Brisbane, Australia