On Thu, 8 Feb 2018 12:53:06 -0600
William Pitcock <nenolod_at_dereferenced.org> wrote:
> On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists_at_gmail.com> wrote:
> > On Thu, 8 Feb 2018 11:23:26 -0600
> >> Meanwhile, the libressl guys have been removing
> >> functionality we depend on, such as support for hardware accelerators
> >> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t
> >> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1
> >> APIs they see as unsuitable.
> > This is a strange take on the situation to say the least.
> I would argue that 32-bit systems not being able to validate
> certificates from CAs who have expiry dates past year 2038 is a major
> security problem. This is caused by the elimination of the TAI64N
> date calculation code.
The fact that libressl developers are not willing to workaround 32 bit
linux time_t is the deal breaker for me. I am not happy to switch back
to openssl. I have been fairly happy with libressl and been willing to
sacrifice pretty much work for the extra security benefits libressl has
given, but the situation we are in now is that we have to choose
- replace linux kernel with some other kernel
- do not support CAs with expiry date past year 2038
- drop 32 bit support
- replace libressl
I wish libressl could keep the 32 bit time_t workaround til linux
kernel had fixed the problem instead of knowingly break things. Now I
don't see we have much of an option since 32 bit linux is basically not
supported by libressl at this point.
Received on Fri Feb 09 2018 - 19:07:38 UTC