Nick Coghlan added the comment:
Transferring a comment I previously made on #27250:
One request I'd make in these discussions is that we avoid using the term
"block" - it makes people think of the /dev/random behaviour (i.e. blocking
intermittently and unhelpfully), rather than the usually-desired "wait for
sufficient entropy on system startup" behaviour. (The only documented case
where that behaviour clearly *isn't* desired is for people writing startup
scripts on Linux that may run before the system entropy pool is initialised,
since doing that has been shown to deadlock the system until the systemd script
watchdog times out)
I'd also request that we keep in mind that any Linux user always remains free
to write the 3-line utility function:
def read_urandom(num_bytes):
with open('/dev/urandom', 'rb') as urandom:
return urandom.read(num_bytes)
If they want to get precisely the Linux /dev/urandom semantics, and not a
Python level abstraction that provides the same kinds of assurances offered by
other *nix platforms and by the Windows crypto APIs. While "os" originated as a
relatively thin wrapper around POSIX APIs, that's far from universally true
these days, especially given the introduction of things like implicit Unicode
handling, implicit EINTR handling, os.scandir, dir_fd handling, and more.
I'd also *STRONGLY* request that we avoid adding any new APIs in relation to
this that mean "Use os.urandom" is no longer the preferred option to obtain
cryptographically strong random numbers in Python. Any such APIs can't be used
in single source Python 2/3 code, they invalidate existing third party
documentation like https://cryptography.io/en/latest/random-numbers/ and they
invalidate answers on Q&A sites like
http://stackoverflow.com/questions/20936993/how-can-i-create-a-random-number-that-is-cryptographically-secure-in-python
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue27266>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
