bug#26093: [PATCH 1/2] gnu: address@hidden: Fix getentropy() calls on kernels < 3.17.

[Marius Bakke]

Leo Famulari <address@hidden> writes:

> * gnu/packages/patches/python-2.7-getentropy-on-old-kernels.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/python.scm (python-2.7)[source]: Use it.
> ---
>  gnu/local.mk                                       |  1 +
>  .../python-2.7-getentropy-on-old-kernels.patch     | 67 
> ++++++++++++++++++++++
>  gnu/packages/python.scm                            |  3 +-
>  3 files changed, 70 insertions(+), 1 deletion(-)
>  create mode 100644 
> gnu/packages/patches/python-2.7-getentropy-on-old-kernels.patch
>
> diff --git a/gnu/local.mk b/gnu/local.mk
> index c74418d0d..ea2e47274 100644
> --- a/gnu/local.mk
> +++ b/gnu/local.mk
> @@ -848,6 +848,7 @@ dist_patch_DATA =                                         
> \
>    %D%/packages/patches/pygpgme-disable-problematic-tests.patch  \
>    %D%/packages/patches/pyqt-configure.patch                  \
>    %D%/packages/patches/python-2-deterministic-build-info.patch       \
> +  %D%/packages/patches/python-2.7-getentropy-on-old-kernels.patch    \
>    %D%/packages/patches/python-2.7-search-paths.patch         \
>    %D%/packages/patches/python-2.7-site-prefixes.patch                \
>    %D%/packages/patches/python-2.7-source-date-epoch.patch    \
> diff --git a/gnu/packages/patches/python-2.7-getentropy-on-old-kernels.patch 
> b/gnu/packages/patches/python-2.7-getentropy-on-old-kernels.patch
> new file mode 100644
> index 000000000..ab4afba1a
> --- /dev/null
> +++ b/gnu/packages/patches/python-2.7-getentropy-on-old-kernels.patch
> @@ -0,0 +1,67 @@
> +This patch resolves a compatibility issue when compiled against glibc
> +2.25
> +and run runder kernels < 3.17:
> +
> +https://bugzilla.redhat.com/show_bug.cgi?id=1410175
> +
> +Upstream bug URL: https://bugs.python.org/issue29157

I would link to https://bugs.python.org/issue29188 as mentioned in the
NEWS entry. Interesting that the NEWS diff doesn't cause conflicts with
the 2.7.13 upgrade (assuming you've tested it). If it does, I think it
can be safely omitted.

Both patches LGTM.

> +
> +Patch copied from upstream source repository:
> +
> +https://github.com/python/cpython/commit/01bdbad3e951014c58581635b94b22868537901c
> +
> +From 01bdbad3e951014c58581635b94b22868537901c Mon Sep 17 00:00:00 2001
> +From: Victor Stinner <address@hidden>
> +Date: Mon, 9 Jan 2017 11:10:41 +0100
> +Subject: [PATCH] Don't use getentropy() on Linux
> +
> +Issue #29188: Support glibc 2.24 on Linux: don't use getentropy() function 
> but
> +read from /dev/urandom to get random bytes, for example in os.urandom().  On
> +Linux, getentropy() is implemented which getrandom() is blocking mode, 
> whereas
> +os.urandom() should not block.
> +---
> + Misc/NEWS       |  5 +++++
> + Python/random.c | 11 +++++++++--
> + 2 files changed, 14 insertions(+), 2 deletions(-)
> +
> +#diff --git a/Misc/NEWS b/Misc/NEWS
> +#index d1f7b5ebbf..fd08a7e0b8 100644
> +#--- a/Misc/NEWS
> +#+++ b/Misc/NEWS
> +#@@ -23,6 +23,11 @@ Extension Modules
> +# Library
> +# -------
> +# 
> +#+- Issue #29188: Support glibc 2.24 on Linux: don't use getentropy() 
> function
> +#+  but read from /dev/urandom to get random bytes, for example in 
> os.urandom().
> +#+  On Linux, getentropy() is implemented which getrandom() is blocking mode,
> +#+  whereas os.urandom() should not block.
> +#+
> +# - Issue #29142: In urllib, suffixes in no_proxy environment variable with
> +#   leading dots could match related hostnames again (e.g. .b.c matches 
> a.b.c).
> +#   Patch by Milan Oberkirch.
> +diff --git a/Python/random.c b/Python/random.c
> +index 57c41ffcd6..000cb36938 100644
> +--- a/Python/random.c
> ++++ b/Python/random.c
> +@@ -97,8 +97,15 @@ win32_urandom(unsigned char *buffer, Py_ssize_t size, int 
> raise)
> + }
> + 
> + /* Issue #25003: Don't use getentropy() on Solaris (available since
> +- * Solaris 11.3), it is blocking whereas os.urandom() should not block. */
> +-#elif defined(HAVE_GETENTROPY) && !defined(sun)
> ++   Solaris 11.3), it is blocking whereas os.urandom() should not block.
> ++
> ++   Issue #29188: Don't use getentropy() on Linux since the glibc 2.24
> ++   implements it with the getrandom() syscall which can fail with ENOSYS,
> ++   and this error is not supported in py_getentropy() and getrandom() is 
> called
> ++   with flags=0 which blocks until system urandom is initialized, which is 
> not
> ++   the desired behaviour to seed the Python hash secret nor for 
> os.urandom():
> ++   see the PEP 524 which was only implemented in Python 3.6. */
> ++#elif defined(HAVE_GETENTROPY) && !defined(sun) && !defined(linux)
> + #define PY_GETENTROPY 1
> + 
> + /* Fill buffer with size pseudo-random bytes generated by getentropy().
> +-- 
> +2.12.0
> +
> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
> index 60f059445..f8e308d52 100644
> --- a/gnu/packages/python.scm
> +++ b/gnu/packages/python.scm
> @@ -132,7 +132,8 @@
>        (patches (search-patches "python-2.7-search-paths.patch"
>                                 "python-2-deterministic-build-info.patch"
>                                 "python-2.7-site-prefixes.patch"
> -                               "python-2.7-source-date-epoch.patch"))
> +                               "python-2.7-source-date-epoch.patch"
> +                               "python-2.7-getentropy-on-old-kernels.patch"))
>        (modules '((guix build utils)))
>        ;; suboptimal to delete failing tests here, but if we delete them in 
> the
>        ;; arguments then we need to make sure to strip out that phase when it
> -- 
> 2.12.0

signature.asc
Description: PGP signature