Python 3.6 uses the new getrandom() function/syscall on Linux and Solaris to get random bytes with no file descriptor: it prevents EMFILE and ENFILE errors or surprises when opening a first file (and looking at its file descriptor).

I propose to copy and adapt Python/random.c from Python 3.5 when Python 3.5 will be updated for the issue #29157. Python 2.7 requires extra changes:

* configure.ac: need to check linux/random.h in AC_CHECK_HEADERS()
* random.c: need to keep vms_urandom() function (Python 2.7 still supports VMS!)
* Python 2.7 doesn't implement the PEP 475 (EINTR) and so don't have functions like _Py_read() which handles EINTR for us.

See also the issue #29157 for the latest change in random.c: prefer getrandom() over getentropy() to support the glibc 2.24.

I think it is far too late to be making these kind of changes to 2.7.

> I think it is far too late to be making these kind of changes to 2.7.

I would prefer to use the "same code" (or almost) on all maintained versions of Python: 2.7, 3.5, 3.6 and 3.7. It should ease the maintenance for bugfixes and enhancements.

It seems like we want to backport security enhancements from Python 3 to Python 2.7: see the PEP 466. Copying random.c from Python 3 would add support for getrandom() which is nice to have since it avoids a private file descriptor (which causes many issues, even if the most important issues are already worked around in Python 2.7 using fstat()).

The minimum required change on Python 2.7 is to not use getentropy() on Linux to support the glibc 2.24: see attached getentropy_linux.patch if you don't want the backport.

> I would prefer to use the "same code" (or almost) on all maintained
> versions of Python: 2.7, 3.5, 3.6 and 3.7. It should ease the
> maintenance for bugfixes and enhancements.

This is VERY far from our historical policy for backports.  Python 2.7 is supposed to be getting more stable over time (that is one of its chief virtues).  We don't want to risk the kind of mini-catastrophe that got published in 3.6 (issue29085).  

If you want to push for this, there needs to be a thorough discussion on python-dev (there are tons of possible backports that could be made if the rationale was "I would prefer to use the same code on all maintained versions").

New changeset 13a39142c047 by Victor Stinner in branch '2.7':
Don't use getentropy() on Linux
https://hg.python.org/cpython/rev/13a39142c047

> This is VERY far from our historical policy for backports.  Python 2.7 is supposed to be getting more stable over time (that is one of its chief virtues).  We don't want to risk the kind of mini-catastrophe that got published in 3.6 (issue29085).

I don't consider that the issue #29085 is a catastrophe and it's just a bug which was already fixed.

Moreover, Python 2.7 and 3.5 don't have _PyOS_URandomNonblock() function and so the _random module is not impacted by this issue.


> If you want to push for this, there needs to be a thorough discussion on python-dev (there are tons of possible backports that could be made if the rationale was "I would prefer to use the same code on all maintained versions").

Sorry, I suffered from the previous discussion about random numbers. I don't want to reopen a new discussion, people would become crazy again.

I just fixed Python/random.c in support glibc 2.24 that's all.

If someone wants the cool getrandom() function/syscall on Python 2.7, please open a new issue. It doesn't really enhance the security, it's just a matter of avoid a file descriptor.