X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by lists.alpinelinux.org (Postfix) with ESMTP id E31235C4E49 for ; Thu, 8 Feb 2018 18:53:07 +0000 (GMT) Received: by mail-qk0-f179.google.com with SMTP id f68so6930498qke.9 for ; Thu, 08 Feb 2018 10:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Eku2+9Cy5w/7EIdhzBH6AqzOHwRX2wyG8nJwPPBW1Q4=; b=c9fUNIGlGSNQaKT/CPO41SwzmExX5e1/Gnwld+6oecH5vWmT0Y4eryE+hNGzEK8dTC saFu/+p3ZYHU61qHJNNoLOnMoW5M/fccPRbjK1R6BtItft0lrp4NAFOd2mTPiL2Uf+t+ ++p7h81frXQRTgGuW0Y0QnmjYR6neXT9iei04h2JHgn8jnPOLWU1u7FAPnEW8qm1V0pI K5TpLwhc2+63wp5VuaWts1TVr6gbTjjXRuyYZxIqxzttIrDa3vttSI+i7ZI+Ru9+yyjf 12yBvuQvvSzDSk414/bHNlkBhO9gPf4GS1eI0NS9CBIUdGwtT5bZDnyhI/6dhisebNie q6VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Eku2+9Cy5w/7EIdhzBH6AqzOHwRX2wyG8nJwPPBW1Q4=; b=CcIH+KeotWseLPQJSzZo9gbsJVzAo/myQoGiBY8Z18mBcMs6h5XMqhFCME03VBDcTF dKZkl43/aNXzmnIbrwQxj24OlLhnP+A5uGo2ROvfIkTLzUE3KzcQbwPuSm9s1XWLLHad jgPCZLQqM3UmELUnxx4NVkuaG5tJdYwbFq5dHiXgzPo6/UMp53Fdi8DKEvB39t3maiDM tS/sjKBabsQ8qJ/G94vW92UiTnkNK1lT8hHVdUknBCDH+ZSjqXS0+n25fXk0guq+TFWI /KWmo1d4K5gIdKvnap50M5D/6prXv5cLtWAO+v41FHV2fHijy9LE5mDfp/jHobQ8G09Z Ui5Q== X-Gm-Message-State: APf1xPBGvqWmLdfnvXNzE2uYCZJKCwQxQtdwybiSd+81HqgMT4iUIoKR Xztf/fB555bDxXAvMDMLr8jeXuN7YC+mt2VMIKPvwQ== X-Google-Smtp-Source: AH8x225wEMkZM+dIcpd1Bpm3PqnkOnFLMX2/Hk7JTXmd023phNNYX3QWCKlG4Vs0pUgR45GPKxP/3PXwBJ0svGm6nuw= X-Received: by 10.55.217.212 with SMTP id q81mr52039qkl.42.1518115987381; Thu, 08 Feb 2018 10:53:07 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.39.100 with HTTP; Thu, 8 Feb 2018 10:53:06 -0800 (PST) In-Reply-To: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> References: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> From: William Pitcock Date: Thu, 8 Feb 2018 12:53:06 -0600 Message-ID: Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation To: Kevin Chadwick Cc: alpine-dev Content-Type: text/plain; charset="UTF-8" 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. > Apis were dropped for good reasons and they have committed to > implementing new API components that seem sensible and are most > desired. However the primary goal is security not functionality and if > anything you could argue that OpenSSL is still way too complex to be > fit for purpose. > > Multiple CVEs have been avoided by LibreSSL already. Those CVEs were not avoided by removal of the functionality I listed above. In fact, the removal of the functionality I listed above has introduced security regressions. >> libressl promised to retain compatibility with 1.0.1g APIs, but has >> failed to do so. > > I am not clear on the versions but I do know that they promised to be a > replacement at the time and whilst I am not really involved I have seen > comments that OpenSSL seem to be purposefully causing issues. This is not the case; LibreSSL have removed APIs that were part of the OpenSSL 1.0.1g set. It is possible today, to have a program which successfully compiles under OpenSSL 1.0.1g (e.g. the release at the time of the LibreSSL fork) and fails to compile under LibreSSL. Accordingly, they broke their promise. >> As such, there is an increasing workload to keep >> packages compatible with libressl as it evolves. Therefore, it is >> obviously not truly a suitable provider for the openssl package, and >> we should switch back to proper openssl as the default. We will > > Do you have a list of packages at all? > > proper!?!? I guess LibreSSL has less resources and hope that is what > you meant. By proper, I mean an implementation that is conformant with the OpenSSL 1.0.1g API, which is what was promised by LibreSSL. > I believe the key protection improvements were/are better in LibreSSL > and so the fix for heartbleed was properly done! The protection improvements are the same: the custom memory management code has been removed from both. > I understand your workload point and that Alpine is far from in > control over this but I don't like how this mail has been written and > wonder what environment caused that? Also, there are other libraries > like mbedtls and boring ssl, aren't these packages breaking > compatibility with them and reducing their scope? (Not an alpine issue > of course) mbedtls has never implemented the OpenSSL API. BoringSSL is not appropriate as a system openssl implementation, it is mostly to support Chromium and other Google products. > So maybe the packages like Python have an agenda or should slow down? > Python could also remove RWX memory requirements by default as a higher > priority? Any interpreter which has the ability to JIT (such as Python 3.6 with an appropriate JIT module loaded) requires RWX. PaX will never allow a page which has been marked PROT_WRITE to ever become PROT_EXEC. It is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1 discussion. > (Python, saying they want to remove existing code for more security > (would it be compiled) but that the existing code is secure). Have they > audited the OpenSSL code themselves? I understand the joy of code > deletion however ;) It is not Python that is the problem here; it is LibreSSL. >> however retain libressl for packages which require it (for example, >> ones using the new libtls APIs). > > A properly simple and secure API? Sure, and that simple and secure API can be implemented using a different TLS library other than LibreSSL, which still has plenty of OpenSSL technical debt. It would make more sense from our perspective to provide an alternative libtls that uses BearSSL or mbedTLS or something else that is very small and already audited. > >> If there is no objection to this proposed change, I intend to do the >> swap next week. > > No objection, just not impressed. Alpine could make a stand but what > difference would it make. A stand for what? LibreSSL has removed support for things we want, such as cryptographic accelerators and TAIN-based date calculations. Neither of those functionality were removed for security reasons, but instead because the OpenBSD developers did not want to deal with maintaining them. I can understand their decision in doing so, but that doesn't mean that the cost-benefit analysis works out favorably for us anymore. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---