PEP 522: BlockingIOError in security sensitive APIs on Linux

[ncoghlan]

No description provided.

[ncoghlan]

@dstufft @njsmith Any comments before I check in this initial draft?

[dstufft]

It might be reasonable to mention somewhere that OS X finds a secure sense source of random so important, that it will kernel panic rather than continue to boot if it can't get enough random during it's boot process.

[holdenweb]

E_NOTENOUGHENTROPY? Wouldn't want the heat death of the universe to break the build ...

Sent from my iPhone

On 16 Jun 2016, at 21:14, Donald Stufft [email protected] wrote:

In pep-0522.txt:

+In all cases, as soon as a call to os.urandom() succeeds, all future
+calls to os.urandom() in that process will succeed (once the operating
+system random number generator is ready after system boot, it remains ready).
+
+
+Proposal
+========
+
+This PEP proposes that in Python 3.6+, os.urandom() be updated to call
+the new Linux `getrandom()syscall in non-blocking mode if available and +raiseBlockingIOError: system random number generator is not ready`` if
+the kernel reports that the call would block.
+
+No changes are proposed for Windows or Mac OS X systems, as neither of those
+platforms provides any mechanism to run Python code before the operating
+system random number generator has been initialised.
It might be reasonable to mention somewhere that OS X finds a secure sense of random so important, that it will kernel panic rather than continue to boot if it can't get enough random during it's boot process.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[dstufft]

A few small nits, but 👍

[ncoghlan]

I merged this to explicitly reserve the PEP number. I'll still give @njsmith a chance to comment before posting to python-dev about it.

[njsmith]

I read it, and thought "hmm, I think this could flow better to make a more compelling argument", and then I started poking at the text and uh. Is a PR tomorrow good? :-)

[ncoghlan]

@njsmith I also didn't find a good place to explicitly state the assumption that random module initialisation and SipHash initialisation will be decoupled from reliance on the behaviour of os.urandom() (However, they could be incorporated into the PEP by saying that they will try os.urandom, and only use their fallbacks if that raises BlockingIOError)

[ncoghlan]

@njsmith Just a heads up that I'm going to be working on major rewrite today - with an extra couple of days to ponder the topic, I have a different overall framing that I think will better sell the idea (although the core proposal remains the same)

[njsmith]

Ah ok I'll at least throw what I've got up in a branch

[njsmith]

#19