From: Oliver Smeeton <oliversmeeton2019@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [News review v2] LibreSSL support discontinued
Date: Mon, 4 Jan 2021 13:39:26 +0000 [thread overview]
Message-ID: <CACkBwDZG=bDqq4ucWKs4Ac7eM_4CizZLMi8oLxDeJKafsRFv_A@mail.gmail.com> (raw)
In-Reply-To: <44d6f59ed2ba7b7f3fa9043925b63065cbf1f7b9.camel@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 4201 bytes --]
You may want to update the Project:LibreSSL
<https://wiki.gentoo.org/wiki/Project:LibreSSL> page to reflect the
decision to drop support for libressl, also you could add a news item to
the libressl package with instructions or a link to instructions for
migrating back to Openssl.
On Mon, 4 Jan 2021 at 09:22, Michał Górny <mgorny@gentoo.org> wrote:
> v2, with additional 'emerge --deselect':
> ---
> Title: LibreSSL support discontinued
> Author: Michał Górny <mgorny@gentoo.org>
> Posted: 202x-xx-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: dev-libs/libressl
>
> Starting 2021-02-01, Gentoo will no longer actively pursue supporting
> dev-libs/libressl as an alternative to dev-libs/openssl. While it will
> still be possible for expert users to use LibreSSL on their systems,
> we are only going to provide support for OpenSSL-based systems. Most
> importantly, we are no longer going to maintain downstream patches for
> LibreSSL support -- it will rely on either package upstreams merging
> such patches themselves, or LibreSSL upstream finally working towards
> better OpenSSL compatibility.
>
> On 2021-02-01, we will mask the relevant USE flags and packages. If
> you
> wish to continue using LibreSSL, you will be able to undo these masks
> for the time being. However, as packages drop patching for LibreSSL
> and the library is eventually removed from ::gentoo, it will become
> necessary to use the user-maintained LibreSSL overlay [1]. As long-
> term
> support for LibreSSL is not guaranteed, we recommend switching
> to OpenSSL instead. More information on removal can be found
> on the relevant bug [2].
>
> To switch before the aforementioned date, remove 'libressl' from your
> USE flags and CURL_SSL targets. Afterwards, it is recommended to
> prefetch all the necessary distfiles before proceeding with the system
> upgrade, in case wget(1) becomes broken in the process:
>
> emerge --fetchonly dev-libs/openssl net-misc/wget
> emerge --fetchonly --changed-use @world
>
> A --changed-use @world upgrade should automatically cause LibreSSL
> to be replaced by OpenSSL, and all affected packages to be rebuilt:
>
> emerge --deselect dev-libs/libressl
> emerge --changed-use @world
>
>
> LibreSSL has been forked off OpenSSL in 2014 to address a number of
> problems with the original package. However, since then OpenSSL
> development gained speed and the original reasons for the fork no
> longer
> apply. Furthermore, LibreSSL started to repeatedly fall behind
> and cause growing compatibility problems. While initially these
> problems were related to packages using old/insecure OpenSSL APIs,
> today
> they are mostly related to LibreSSL missing newer OpenSSL APIs
> (yet declaring false compatibility with newer OpenSSL versions).
>
> With the little testing it gets, our developers and users had to put
> a significant effort into fixing upstream packages. In some cases
> (e.g. Qt), upstream has explicitly refused to support LibreSSL, forcing
> us to maintain the patches forever. This in turn means that
> security fixes, regular version bumps or end-user system upgrades are
> often delayed because of necessary LibreSSL patching. What is even
> worse, major runtime issues managed to sneak in that broke production
> systems running LibreSSL in the past.
>
> To the best of our knowledge, the only benefit LibreSSL has over
> OpenSSL
> right now is the additional libtls library. For this reason, we have
> packaged dev-libs/libretls which is a port of this library that links
> to OpenSSL.
>
> All these issued considered, we came to the conclusion that OpenSSL
> should remain the only supported production option for Gentoo systems.
> While the flexibility of Gentoo should make it possible to keep using
> LibreSSL going forward, the effort necessary to provide first-class
> official support for LibreSSL has proven to outweigh the benefit.
>
> [1] https://gitweb.gentoo.org/repo/proj/libressl.git/tree/README.md
> [2] https://bugs.gentoo.org/762847
> ---
>
>
>
>
> --
> Best regards,
> Michał Górny
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4969 bytes --]
next prev parent reply other threads:[~2021-01-04 13:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-03 20:47 [gentoo-dev] [News review] LibreSSL support discontinued Michał Górny
2021-01-04 8:25 ` Stefan Strogin
2021-01-04 9:18 ` Marek Szuba
2021-01-04 9:20 ` Michał Górny
2021-01-04 9:21 ` [gentoo-dev] [News review v2] " Michał Górny
2021-01-04 13:39 ` Oliver Smeeton [this message]
2021-01-04 13:46 ` Toralf Förster
2021-01-04 14:00 ` Oliver Smeeton
2021-01-04 14:24 ` Aaron Bauman
2021-01-04 14:30 ` Michał Górny
2021-01-04 14:40 ` [gentoo-dev] [News review] " Marc Schiffbauer
2021-01-04 15:08 ` Michał Górny
2021-01-04 15:09 ` [gentoo-dev] [News review v3] " Michał Górny
2021-01-04 19:59 ` Ulrich Mueller
2021-01-04 20:48 ` Michał Górny
2021-01-04 20:51 ` Michał Górny
2021-01-05 11:17 ` [gentoo-dev] [News review] " Michał Górny
2021-03-27 1:47 ` Thomas Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACkBwDZG=bDqq4ucWKs4Ac7eM_4CizZLMi8oLxDeJKafsRFv_A@mail.gmail.com' \
--to=oliversmeeton2019@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox