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.

classification
Title: Backport random.c from Python 3.5 to Python 2.7
Type: security Stage:
Components: Versions: Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, christian.heimes, python-dev, rhettinger, vstinner
Priority: normal Keywords: patch

Created on 2017-01-06 23:53 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
getentropy_linux.patch vstinner, 2017-01-07 01:45 review
Messages (6)
msg284876 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-06 23:53
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.
msg284878 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-01-07 00:15
I think it is far too late to be making these kind of changes to 2.7.
msg284880 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-07 01:45
> 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.
msg284929 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-01-07 19:43
> 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").
msg285033 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2017-01-09 10:22
New changeset 13a39142c047 by Victor Stinner in branch '2.7':
Don't use getentropy() on Linux
https://hg.python.org/cpython/rev/13a39142c047
msg285034 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-09 10:26
> 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.
History
Date User Action Args
2022-04-11 14:58:41adminsetgithub: 73374
2017-01-09 10:26:37vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg285034
2017-01-09 10:22:23python-devsetnosy: + python-dev
messages: + msg285033
2017-01-07 20:03:24christian.heimessetnosy: + christian.heimes
2017-01-07 19:43:09rhettingersetnosy: + benjamin.peterson
messages: + msg284929
2017-01-07 01:45:20vstinnersetfiles: + getentropy_linux.patch
keywords: + patch
messages: + msg284880
2017-01-07 00:15:11rhettingersetnosy: + rhettinger
messages: + msg284878
2017-01-06 23:53:54vstinnercreate