Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] [News review] LibreSSL support discontinued
Date: Sun, 03 Jan 2021 20:47:40
1 Hello,
3 Please review the news item inlined below. This is based on what
4 I discussed with blueness (LibreSSL team lead). The news item is kinda
5 long-ish because I wanted to include the full rationale since I believe
6 our users will find it desirable to know it.
8 If it's ok, I'd like to push it soonish. This will give people around
9 4 weeks to prepare and/or migrate their systems manually before being
10 hit by the masks. Afterwards, we'll mask libressl with a prolonged
11 removal date. I'm thinking of 3 months since I suspect that our
12 packages will start strongly requiring OpenSSL by then.
14 I'm mentioning the LibreSSL overlay since one of our users is
15 interested in maintaining it. It will probably be the best alternative
16 for users who want to continue fighting the lost cause without causing
17 major problems for Gentoo mainline.
20 ---
21 Title: LibreSSL support discontinued
22 Author: Michał Górny <mgorny@g.o>
23 Posted: 202x-xx-xx
24 Revision: 1
25 News-Item-Format: 2.0
26 Display-If-Installed: dev-libs/libressl
28 Starting 2021-02-01, Gentoo will no longer actively pursue supporting
29 dev-libs/libressl as an alternative to dev-libs/openssl. While it will
30 still be possible for expert users to use LibreSSL on their systems,
31 we are only going to provide support for OpenSSL-based systems. Most
32 importantly, we are no longer going to maintain downstream patches for
33 LibreSSL support -- it will rely on either package upstreams merging
34 such patches themselves, or LibreSSL upstream finally working towards
35 better OpenSSL compatibility.
37 On 2021-02-01, we will mask the relevant USE flags and packages. If you
38 wish to continue using LibreSSL, you will be able to undo these masks
39 for the time being. However, as packages drop patching for LibreSSL
40 and the library is eventually removed from ::gentoo, it will become
41 necessary to use the user-maintained LibreSSL overlay [1]. As long-term
42 support for LibreSSL is not guaranteed, we recommend switching
43 to OpenSSL instead. The more information on removal can be found
44 on the relevant bug [2].
46 To switch before the aforementioned date, remove 'libressl' from your
47 USE flags and CURL_SSL targets. Afterwards, it is recommended to
48 prefetch all the necessary distfiles before proceeding with the system
49 upgrade, in case wget(1) becomes broken in the process:
51 emerge --fetchonly dev-libs/openssl net-misc/wget
52 emerge --fetchonly --changed-use @world
54 A --changed-use @world upgrade should automatically cause LibreSSL
55 to be replaced by OpenSSL, and all affected packages to be rebuilt:
57 emerge --changed-use @world
60 LibreSSL has been forked off OpenSSL in 2014 to address a number of
61 problems with the original package. However, since then OpenSSL
62 development gained speed and the original reasons for the fork no longer
63 apply. Furthermore, LibreSSL started to repeatedly fall behind
64 and cause growing compatibility problems. While initially these
65 problems were related to packages using old/insecure OpenSSL APIs, today
66 they are mostly related to LibreSSL missing newer OpenSSL APIs
67 (yet declaring false compatibility with newer OpenSSL versions).
69 With the little testing it gets, our developers and users had to put
70 a significant effort into fixing upstream packages. In some cases
71 (e.g. Qt), the upstream has explicitly refused to support LibreSSL,
72 requiring us to maintain the patches forever. This in turn means that
73 security fixes, regular version bumps or end-user system upgrades are
74 often delayed because of necessary LibreSSL patching. What is even
75 worse, major runtime issues managed to sneak in that broke production
76 systems running LibreSSL in the past.
78 To the best of our knowledge, the only benefit LibreSSL has over OpenSSL
79 right now is the additional libtls library. For this reason, we have
80 packaged dev-libs/libretls which is a port of this library that links
81 to OpenSSL.
83 All these issued considered, we came to the conclusion that OpenSSL
84 should remain the only supported production option for Gentoo systems.
85 While the flexibility of Gentoo should make it possible to keep using
86 LibreSSL going forward, the effort necessary to provide a first-class
87 official support for LibreSSL has proven to outweigh the benefit.
89 [1]
90 [2]
91 ---
94 --
95 Best regards,
96 Michał Górny