[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:
>
> https://github.com/libressl-portable/portable/issues/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:
>
> https://bugs.python.org/issue29157
>
> 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.
Thoughts?
Thanks,
Ludo’.
¹ 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.")
(base32
"0c4awq45cl757fv7f7f75i5i0ibc6v7ns13n7xvfak7chv2lrqql"))))
(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")))
(native-search-paths
;; FIXME: These two variables must designate a single file or directory
;; and are not actually "search paths." In practice it works OK in