PEP 522: BlockingIOError in security sensitive APIs on Linux#13
PEP 522: BlockingIOError in security sensitive APIs on Linux#13ncoghlan merged 2 commits intopython:masterpython/peps:masterfrom ncoghlan:security-sensitive-rngncoghlan/peps:security-sensitive-rngCopy head branch name to clipboard
Conversation
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 notifications@github.com wrote:
In pep-0522.txt:
+In all cases, as soon as a call to
os.urandom()succeeds, all future
+calls toos.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.
|
A few small nits, but 👍 |
- Note MAC OS X kernel panic behaviour - Fix copy & paste error in example function name - Note getrandom() doesn't offer /dev/urandom behaviour
|
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. |
|
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? :-) |
|
@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) |
|
@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) |
|
Ah ok I'll at least throw what I've got up in a branch |
…g-patch-1 Fix python#13 for PEP 458
No description provided.