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 lemburg
Recipients lemburg, matejcik, rhettinger, socketpair, vstinner
Date 2015-10-20.16:26:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445358380.05.0.625085839576.issue25420@psf.upfronthosting.co.za>
In-reply-to
Content
I think Jan has a point there. An import should not cause the whole interpreter to hang.

Wouldn't it be possible to have the getrandom() call be done lazily to avoid this and only have it block when the RNG from the random is actually being used ?

Or alternatively, make things more robust by avoiding to call the API on systems which are known to have blocking problems and then reverting to using /dev/urandom directly instead ?

Note that the RNG does already use a fallback solution for systems which don't provide os.urandom. Also note that os.urandom() is documented (indirectly via man 4 urandom) to not be blocking. If it blocks on some systems, we should add a work-around for those, just like Python/random.c does for Solaris.

BTW: Is there a way to determine whether enough entropy has been gathered without doing a blocking call ? This could be used to find out whether getrandom() will potentially block.
History
Date User Action Args
2015-10-20 16:26:20lemburgsetrecipients: + lemburg, rhettinger, vstinner, matejcik, socketpair
2015-10-20 16:26:20lemburgsetmessageid: <1445358380.05.0.625085839576.issue25420@psf.upfronthosting.co.za>
2015-10-20 16:26:20lemburglinkissue25420 messages
2015-10-20 16:26:19lemburgcreate