Author larry
Recipients Theodore Tso, dstufft, larry, ncoghlan, vstinner
Date 2016-06-08.23:43:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465429433.18.0.561045548119.issue27266@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-06-08 23:43:53larrysetrecipients: + larry, ncoghlan, vstinner, dstufft, Theodore Tso
2016-06-08 23:43:53larrysetmessageid: <1465429433.18.0.561045548119.issue27266@psf.upfronthosting.co.za>
2016-06-08 23:43:53larrylinkissue27266 messages
2016-06-08 23:43:52larrycreate