Larry Hastings added the comment: Let me make one more thing clear. I'm willing for os.urandom() to try to use getrandom(GRND_NOBLOCK) (or whatever the flag is called). This will not block unless the entropy pool is low--which almost never happens. So 99.9999% of the time, os.urandom() should return lovely high-quality, cryptographically-safe random numbers.
Really this entire debacle is an argument about this funny edge cases, like "you create a new VM and run python3 as PID 0 and your bad sysadmins don't manage the entropy pool and the entropy pool never fills". What should the code do in that situation? Is it acceptable to use low-quality bits from /dev/urandom? Or do they need cryptographically-strong random numbers? I quote the Zen: "In the face of ambiguity, refuse the temptation to guess." Thus, we shouldn't block on Linux, and we should behave predictably like /dev/urandom does on the local machine. This leads me to one reason why I oppose block=. It's hiding the complexity of the local system with even more complexity, and makes it hard to reason about what the code is doing. The os module should behave in a predictable manner, as if it was a thin shell around the local system call. Given that it's impossible to block on Linux and get higher-quality random bits, and it's impossible to *not* block on FreeBSD and get lower-quality random bits, adding block= to os.urandom() means its behavior becomes inobvious and hard to predict. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27266> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
