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

[Nick Coghlan]

On 24 June 2016 at 04:34, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2016-06-24 2:46 GMT+02:00 Donald Stufft <donald at stufft.io>:
>> 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.
>
> Maybe I'm wrong, but *starting* to raise BlockingIOError looks like
> the opposite direction taken by Python with EINTR (PEP 475).

The difference I see here is that EINTR really can happen at any time,
while the transition from "system RNG is not ready" to "system RNG is
ready" is a once-per-boot deal (and in most cases, the operating
system itself handles making sure the RNG is initialised before it
starts running userspace processes).

As such, the idioms I currently have in PEP 522 are wrong - the "wait
for the system RNG or not" decision wouldn't be one to be made on a
per-call basis, but rather on a per-__main__ execution basis, with
developers choosing which user experience they want to support on
systems with a non-blocking /dev/urandom:

* this application will fail if you run it before the system RNG is
ready (so you may need to add "ExecStartPre=python3 -c 'import
secrets; secrets.wait_for_system_rng()'" in your systemd unit file)
* this application implicitly calls "secrets.wait_for_system_rng()"
and hence may block waiting for the system RNG if you run it before
the system RNG is ready

The default state of Python 3.6+ applications would be the first one,
and I think that's an entirely reasonable default - if you're writing
userspace code that runs before the system RNG is ready, you're out of
the world of normal software development and into the world of
operating system developers, system integrators and embedded system
designers.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia