[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: Wed, 19 Apr 2017 22:12:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Mark H Weaver <address@hidden> skribis:

> Leo Famulari <address@hidden> writes:
>> 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")))
> Ludo's approach looks good to me.

Thanks for checking.  Committed.

>> 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 :)
> It's not just about not providing substitutes.  At present, our libressl
> simply won't work properly on systems with older kernels, including
> and our x86 build slaves.
> One issue is that there's a longstanding hope for us to switch to using
> libressl for most or all packages that currently use openssl.  We would
> be blocked from doing that if we accept that our libressl won't work on
> older kernels.

Yeah, I think we have to be consistent about what our kernel requirement
is.  With libc unconditionally providing syscall wrappers like this one,
it’s easy to let incompatibilities slip through.


reply via email to

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