1 |
Hello, |
2 |
|
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. |
7 |
|
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. |
13 |
|
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. |
18 |
|
19 |
|
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 |
27 |
|
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. |
36 |
|
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]. |
45 |
|
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: |
50 |
|
51 |
emerge --fetchonly dev-libs/openssl net-misc/wget |
52 |
emerge --fetchonly --changed-use @world |
53 |
|
54 |
A --changed-use @world upgrade should automatically cause LibreSSL |
55 |
to be replaced by OpenSSL, and all affected packages to be rebuilt: |
56 |
|
57 |
emerge --changed-use @world |
58 |
|
59 |
|
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). |
68 |
|
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. |
77 |
|
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. |
82 |
|
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. |
88 |
|
89 |
[1] https://gitweb.gentoo.org/repo/proj/libressl.git/tree/README.md |
90 |
[2] https://bugs.gentoo.org/762847 |
91 |
--- |
92 |
|
93 |
|
94 |
-- |
95 |
Best regards, |
96 |
Michał Górny |