[Security-sig] PEP 522: Allow BlockingIOError in security sensitive APIs on Linux

Nick Coghlan ncoghlan at gmail.com
Thu Jun 23 22:08:02 EDT 2016


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


More information about the Security-SIG mailing list