X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 56B495C3A8D for ; Fri, 9 Feb 2018 18:07:43 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 2A3489E2545; Fri, 9 Feb 2018 18:07:43 +0000 (GMT) Received: from ncopa-macbook.copa.dup.pw (unknown [187.60.66.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 8B1909E1CE9; Fri, 9 Feb 2018 18:07:42 +0000 (GMT) Date: Fri, 9 Feb 2018 19:07:38 +0100 From: Natanael Copa To: William Pitcock Cc: Kevin Chadwick , alpine-dev Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation Message-ID: <20180209190738.08862937@ncopa-macbook.copa.dup.pw> In-Reply-To: References: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 8 Feb 2018 12:53:06 -0600 William Pitcock wrote: > Hello, > > On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick 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 between: - 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. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---