On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Courtès wrote: > 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?
> + ;; 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")))
If we are committed to building glibc with the 2.6 kernel headers, and
to providing substitutes for libressl and it's dependent packages, then
I think this patch is a good option.
But, it's a bit of a shame to leave this ~2.5 year old feature behind,
especially when the 2.6 Linux series is not even part of the Linux
long-term-support project. [0] These kernels *will* live for a long time
through support from RHEL; their most recent kernel on RHEL7 is 3.10.
However, I don't fully understand the impact of building glibc with a
newer set of headers, so my objection is a weak one :)
Personally, I don't think it's paramount to offer substitutes for the
packages in question. But I know this is an unpopular position, in
general :)
[0]
https://ltsi.linuxfoundation.org/
https://www.kernel.org/
signature.asc
Description: PGP signature
