[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/02: gnu: libressl: Update to 2.5.3.

From: Ludovic Courtès
Subject: Re: 01/02: gnu: libressl: Update to 2.5.3.
Date: Thu, 13 Apr 2017 17:08:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Leo Famulari <address@hidden> skribis:

> This is libressl-portable bug #290:
> There is a problem with using getentropy() or getrandom() from
> glibc-2.25 with Linux < 3.17, when these syscalls where introduced.
> Basically, glibc will return ENOSYS, which applications are not handling
> properly.
> I expect the build to succeed on armhf, where I believe the builders
> have kernels > 3.17.
> In the case of libressl, the developers have closed as WONTFIX, although
> perhaps they could be persuaded to make libressl handle ENOSYS somehow.
> Cpython hit the same problem, and they worked around it. This means that
> the Python interpreters Hydra builds for x86_64 and i686 not use the new
> getentropy() / getrandom() syscalls, even though many Guix users and
> probably all GuixSD users have more recent kernels:
> Can we disable the build on Hydra without marking the package as
> non-substitutable?

A simple approach is to force LibreSSL to always use its non-getentropy
code, and lift this restriction once we clearly require newer kernels¹.
The attached patch does that.



¹ We currently build libc with "--enable-kernel=2.6.32", and this is
  pretty much what defines our minimal kernel version requirement.

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 1c99a3ad7..5fe35a535 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -442,6 +442,10 @@ required structures.")
     (build-system gnu-build-system)
+    (arguments
+     ;; Do as if 'getentropy' was missing since older Linux kernels lack it
+     ;; and libc would return ENOSYS, which is not properly handled.
+     '(#:configure-flags '("ac_cv_func_getentropy=no")))
       ;; FIXME: These two variables must designate a single file or directory
       ;; and are not actually "search paths."  In practice it works OK in

reply via email to

[Prev in Thread] Current Thread [Next in Thread]