This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Colm Buckley, doko, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.09:55:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2016-06-07 09:55:53vstinnersetrecipients: + vstinner, lemburg, rhettinger, doko, larry, matejcik, ned.deily, skrah, python-dev, martin.panter, ztane, thomas-petazzoni, Colm Buckley
2016-06-07 09:55:53vstinnersetmessageid: <>
2016-06-07 09:55:53vstinnerlinkissue26839 messages
2016-06-07 09:55:52vstinnercreate