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 Colm Buckley
Recipients Colm Buckley, Lukasa, alex, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.13:33:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465306393.52.0.974106429924.issue26839@psf.upfronthosting.co.za>
In-reply-to
Content
Here's where things stand, as I currently see it.

Under certain circumstances, under Linux at least, calls to getrandom() will block. Specifically, they will block if the system's PRNG has been insufficiently initialized. Depending on the nature of the host, this block can be for a long time - delays of over 90 seconds have been observed.

This does not just affect VMs; physical systems are also affected.

Even if an application does not explicitly request random data, Python calls this function early in its execution to initialize the per-process hash seed (in _PyRandom_Init()).

The net effect is that *all* invocations of Python will block at startup if the system RNG is blocking. The only reason this is being called out as Linux-specific is that the behavior has been noticed in Linux.

I posit that it's *highly undesirable* to have Python block on the system RNG even when called in non-crypto contexts. (The specific trigger for this bug is the current behavior of Debian's 'testing' branch which calls a Python script very shortly after boot to parse crontab entries.)

Regardless of what behavior is expected of module functions such as os.urandom(), a blocking RNG must not be used to initialize _Py_HashSecret, even at the expense of predictability.

I agree that ultimately a variety of interfaces should be exposed, to allow developers to choose sensible compromises between performance and security. However, the current patchset makes the minimal change to system behavior while allowing a practical path forward.

My personal preference would be for os.urandom(n) to favor non-blocking operation over cryptographic security, and either add os.random() or add an optional parameter to os.urandom() to make the opposite trade-off.

Given the deadline requested by Larry for 3.5.2, however, can I suggest that the minimal solution is the one already proposed by myself and Victor?

(Aside: "you should fix Linux" is not really within the realm of practicality.)
History
Date User Action Args
2016-06-07 13:33:13Colm Buckleysetrecipients: + Colm Buckley, lemburg, rhettinger, doko, vstinner, larry, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, dstufft, Lukasa, thomas-petazzoni
2016-06-07 13:33:13Colm Buckleysetmessageid: <1465306393.52.0.974106429924.issue26839@psf.upfronthosting.co.za>
2016-06-07 13:33:13Colm Buckleylinkissue26839 messages
2016-06-07 13:33:12Colm Buckleycreate