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 Lukasa
Recipients Colm Buckley, Lukasa, Theodore Tso, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-08.08:16:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465373794.05.0.31528321225.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
> If you read #25003, it's clear that /dev/urandom is a well-known UNIX facility with well-known, predictable behavior.  One behavior that I'll draw particular attention to now: it will never block.  If the system is low on entropy, /dev/urandom will produce lower-quality random bits.

That's not accurate.

/dev/urandom is a well-known UNIX facility, yes, but it does not have consistent behaviour across Unices. The behaviour you've described here Larry is a well-known *Linux* behaviour.

However, on other Unices the behaviour is different. Here, for example, is the relevant man page from Mac OS X ("man 4 random"):

     /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will
     produce lower quality output if the entropy pool drains, while
     /dev/random will prefer to block and wait for additional entropy to be
     collected.  With Yarrow, this choice and distinction is not necessary,
     and the two devices behave identically. You may use either.

Note the specific wording here: "the two devices behave identically". That is to say, on OS X both /dev/random and /dev/urandom are identical devices, and that includes the fact that both will in principle block if used without sufficient entropy.

OS X's implementation is a direct descendent of FreeBSD's, so the same caveats apply there, and in fact all the BSDs have this exact same behaviour.

So, again, I repeat my objection from above: if the concern is that starting Python must never block, then Python must *never* read from /dev/urandom on startup. Otherwise, Python *can* block on BSDs (OS X included in principle, though in practice I doubt Apple will use Python that early in boot).

At this point I literally no longer care whether os.urandom() is just a wrapper around /dev/urandom: we can look back on this in 10 years and see how we feel about the choices made by core dev at that time. But if we're arguing that this issue is about "Python must never block at startup", then we really have to acknowledge that /dev/urandom *can block* on some Unices, and so is entirely unacceptable for reading at startup.
History
Date User Action Args
2016-06-08 08:16:34Lukasasetrecipients: + Lukasa, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, thomas-petazzoni, Colm Buckley, Theodore Tso
2016-06-08 08:16:34Lukasasetmessageid: <1465373794.05.0.31528321225.issue26839@psf.upfronthosting.co.za>
2016-06-08 08:16:34Lukasalinkissue26839 messages
2016-06-08 08:16:33Lukasacreate