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

[Donald Stufft]

> On Jun 23, 2016, at 9:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 23 June 2016 at 17:46, Donald Stufft <donald at stufft.io> wrote:
>> 
>>> On Jun 23, 2016, at 8:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> 
>>> The argument chain runs:
>>> 
>>> - if such software doesn't exist, it doesn't matter which behaviour we choose
>>> - if we're wrong and it does exist, we can choose how it fails:
>>> - blocking (with associated potential for init system deadlock)
>>> - throwing an exception
>>> 
>>> Given the choice between debugging an apparent system hang and an
>>> unexpected exception when testing against a new version of a platform,
>>> I'll choose the exception every time.
>> 
>> 
>> I think the biggest argument to blocking is that there really exist two sort of situations that blocking can happen in:
>> 
>> * It blocks for a tiny amount (maybe <1s) and nobody ever notices and people feel like things “just work”.
>> * It blocks for a long amount of time (possibly forever depending on where in the boot sequence Python is being used) and it hangs for a long time (or forever).
>> 
>> In the second case I think it’s pretty obvious that an exception is better than hanging forever, but in the first case an exception might actually cause people to go out of their way to do something bad to “stop the pain”. My personal preference is waffling back and forth between them based on which of the two above I feel are more likely to occur in practice.
> 
> That's fair, and it's a large part of why I realised PEP 522 needed a
> standard library answer for "just wait until the system RNG is ready,
> please".
> 
> I'll also note that I'm open to being convinced that it's OK for
> "import secrets" to be that answer - my main argument against it is
> just a general principle that imports shouldn't have side effects, and
> blocking waiting for an external state change is a side effect.
> 
> 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.

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.


—
Donald Stufft