STINNER Victor added the comment:
I'm the author of the os.urandom() change which introduced the usage of the new
getrandom() syscall: see the issue #22181. My motivation was to avoid the
internal file descriptor to read /dev/urandom. In some corner cases (issue
#18756), creating a file descriptor fails with EMFILE. Python introduced a
workaround keeping the file descriptor open (issue #18756), but this change
introduced new issues (issue #21207)...
When I modified os.urandom(), I was aware that getrandom() can block at
startup, but I saw this feature as a good thing for Python. It doesn't seem
like a good idea to generate low quality random numbers. I expected that such
system *quickly* gets enough good entropy. With this issue, we now have more
information: "quickly" means in fact longer than 1 minute! ("causing a
90-second boot delay", msg265477).
Blocking Python startup longer than 1 minute just to get good quality random
numbers doesn't seem worth it to me. It is clearly seen as a regression
compared to Python 2 (which doesn't use getrandom() but reads /dev/urandom). I
understand that the behaviour is also seen as a bug when compared to other
programming languages or applications.
For all these reasons, I pushed Colm's change.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue26839>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
