Author vstinner
Recipients christian.heimes, vstinner
Date 2017-01-04.17:33:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za>
In-reply-to
Content
A new getentropy() function was recently added to the glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=17252

When the Python/random.c file was written (by me), the getentropy() function was only supported on OpenBSD. Later, random.c was modified to *not* use getentropy() on Solaris (Issue #25003).

The problem is that py_getentropy() doesn't handle ENOSYS, and so Python fails at startup with a fatal error (Python 3.6):
   Fatal Python error: failed to get random numbers to initialize Python
or (Python 3.5):
   Fatal Python error: getentropy() failed

The bug was first reported in Fedora 26 (rawhide):
https://bugzilla.redhat.com/show_bug.cgi?id=1410175

Attached patch (written for the default branch) should fix these issues:

* Prefer getrandom() syscall over getentropy() function: getrandom() supports blocking and non-blocking mode on Linux, whereas getentropy() doesn't
* Enhance py_getentropy() to handle ENOSYS: fallback on reading from /dev/urandom and remember that the function doesn't work

I'm not sure that handling ENOSYS is required, since it's no more used on Linux, but it shouldn't hurt. I don't know if py_getentropy() should also handle EPERM?

py_getrandom() catchs errors: EAGAIN, EINTR, EPERM and ENOSYS.

With the patch, py_getentropy() catchs ENOSYS error.
History
Date User Action Args
2017-01-04 17:33:01vstinnersetrecipients: + vstinner, christian.heimes
2017-01-04 17:33:01vstinnersetmessageid: <1483551181.22.0.980001779001.issue29157@psf.upfronthosting.co.za>
2017-01-04 17:33:01vstinnerlinkissue29157 messages
2017-01-04 17:33:01vstinnercreate