PEP 522: *BSD behaviour is variant specific

This commit is contained in:
Nick Coghlan 2016-06-21 18:17:54 -07:00
parent b819c243a3
commit 914dfa153e
1 changed files with 11 additions and 8 deletions

View File

@ -132,12 +132,13 @@ unfortunately the exact conditions that trigger this are difficult to predict,
and when it occurs then there is no direct way for userspace to tell it has and when it occurs then there is no direct way for userspace to tell it has
happened without querying operating system specific interfaces. happened without querying operating system specific interfaces.
On \*BSD systems, encountering this situation means ``os.urandom()`` will block On \*BSD systems (if the particular \*BSD variant allows the problem to occur
waiting for the system random number generator to be ready - the associated at all), encountering this situation means ``os.urandom()`` will either block
waiting for the system random number generator to be ready (the associated
symptom would be for the affected script to pause unexpectedly on the first symptom would be for the affected script to pause unexpectedly on the first
call to ``os.urandom()``. call to ``os.urandom()``) or else will behave the same way as it does on Linux.
However, on Linux, in Python versions up to and including Python 3.4, and in On Linux, in Python versions up to and including Python 3.4, and in
Python 3.5 maintenance versions following Python 3.5.2, there's no clear Python 3.5 maintenance versions following Python 3.5.2, there's no clear
indicator to developers that their software may not be working as expected indicator to developers that their software may not be working as expected
when run early in the Linux boot process, or on hardware without good when run early in the Linux boot process, or on hardware without good
@ -216,9 +217,11 @@ As no changes are proposed for operating systems other than Linux,
``os.urandom()`` retains its existing behaviour as a nominally blocking API ``os.urandom()`` retains its existing behaviour as a nominally blocking API
that is non-blocking in practice due to the difficulty of scheduling Python that is non-blocking in practice due to the difficulty of scheduling Python
code to run before the operating system random number generator is ready. We code to run before the operating system random number generator is ready. We
believe it may be possible on \*BSD, but nobody has explicitly demonstrated believe it may be possible to encounter problems akin to those described in
that. On Mac OS X and Windows, it appears to be straight up impossible to this PEP on at least some \*BSD variants, but nobody has explicitly
even try to run a Python interpreter that early in the boot process. demonstrated that. On Mac OS X and Windows, it appears to be straight up
impossible to even try to run a Python interpreter that early in the boot
process.
On Linux, ``os.urandom()`` retains its status as a guaranteed non-blocking API. On Linux, ``os.urandom()`` retains its status as a guaranteed non-blocking API.
However, the means of achieving that status changes in the specific case of However, the means of achieving that status changes in the specific case of
@ -242,7 +245,7 @@ regardless of whether or not they perform security sensitive operations:
- applications that are only run after the system RNG is ready - applications that are only run after the system RNG is ready
Applications in this category simply won't encounter the new exception, so it Applications in this category simply won't encounter the new exception, so it
will be reasonable for developers to simply wait and see if they receive will be reasonable for developers to wait and see if they receive
Python 3.6 compatibility bugs related to the new runtime behaviour, rather than Python 3.6 compatibility bugs related to the new runtime behaviour, rather than
attempting to pre-emptively determine whether or not they're affected. attempting to pre-emptively determine whether or not they're affected.