Mark H Weaver <m...@netris.org> skribis:
> Leo Famulari <l...@famulari.name> 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
> hydra.gnu.org 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.
Ludo’.
