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 <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com