1 |
On Mon, 2020-12-28 at 13:59 -0500, Anthony G. Basile wrote: |
2 |
> On 12/28/20 3:56 AM, Michał Górny wrote: |
3 |
> > Hello, developers and Gentoo LibreSSL team. |
4 |
> > |
5 |
> > TL;DR: is there really a point in continuing the never-ending |
6 |
> > always- |
7 |
> > regressing struggle towards supporting LibreSSL in Gentoo? |
8 |
> > |
9 |
> > |
10 |
> > I would like to discuss the possibility of discontinuing LibreSSL |
11 |
> > support in Gentoo in favor of sticking with OpenSSL. Similarly how |
12 |
> > we |
13 |
> > ended up deciding that fighting for libav was unpractical and the |
14 |
> > vast |
15 |
> > majority of users are using ffmpeg (because they didn't really have |
16 |
> > a choice), today it seems that LibreSSL is suffering the same fate. |
17 |
> > |
18 |
> > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? |
19 |
> > To be honest, I don't think so. In 2014, it might have represented |
20 |
> > a new quality. But today, OpenSSL is alive and kicking, and |
21 |
> > LibreSSL |
22 |
> > finds it hard to keep up. |
23 |
> > |
24 |
> > The vast majority of software is not tested against LibreSSL. |
25 |
> > While |
26 |
> > patches are usually trivial and we have people that submit them, |
27 |
> > I find many of them short-sighted. Just look at [1]. Sure, it |
28 |
> > fixes |
29 |
> > the build today but it disabled the feature for all foreseeable |
30 |
> > future. |
31 |
> > How likely is it that somebody will submit another patch reenabling |
32 |
> > it |
33 |
> > with a future LibreSSL version? |
34 |
> > |
35 |
> > While normally I strongly prefer submitting such patches upstream, |
36 |
> > that |
37 |
> > makes things even worse. I mean, I wouldn't be surprised if there |
38 |
> > were |
39 |
> > dozens of packages today that are crippled with LibreSSL just |
40 |
> > because |
41 |
> > somebody fixed the build in the past and never revisited the |
42 |
> > problem. |
43 |
> > |
44 |
> > This somewhat resembles running in circles. Packages kept being |
45 |
> > broken |
46 |
> > with LibreSSL because rarely anyone is using it. And rarely anyone |
47 |
> > is |
48 |
> > using LibreSSL because the apparent benefit (or lack thereof) does |
49 |
> > not |
50 |
> > justify the constant breakage (plus invisible regressions). |
51 |
> > |
52 |
> > All this considered, provided that nobody is able to find a good |
53 |
> > reason |
54 |
> > to use LibreSSL, I would like to propose that we stop patching |
55 |
> > packages, discontinue support for it and last rite it. |
56 |
> > |
57 |
> > |
58 |
> > [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892 |
59 |
> > |
60 |
> |
61 |
> I'm the current project lead. I inherited it back in the day from |
62 |
> hasufel. It originally had promise of being better than openssl with |
63 |
> 100% compatibility. I hung on because I trusted that team but it has |
64 |
> become more of a hassle than its worth. I am in favor of removing |
65 |
> it. |
66 |
> If we decide to do so, how should we proceed? |
67 |
|
68 |
I think the usual plan for this kind of thing is to: |
69 |
|
70 |
1. Issue a news item with the planned cutoff date, and suggest people |
71 |
that they can set USE=-libressl to switch earlier. |
72 |
|
73 |
2. At the cutoff date, use.mask libressl flag. |
74 |
|
75 |
3. package.mask libressl itself to give people a clear message. |
76 |
|
77 |
|
78 |
I might be wrong but I think the update should proceed cleanly with |
79 |
--changed-use/--newuse. The PM will trigger the rebuilds, |
80 |
and preserved-libs should take care of keeping libressl libs for |
81 |
as long as necessary (yeah, I know relying on preserved-libs sucks). |
82 |
|
83 |
The only problem that I can think of are packages that depend |
84 |
on libressl specifically and do not support openssl. I don't think we |
85 |
have anything like that but I'll double check. |
86 |
|
87 |
-- |
88 |
Best regards, |
89 |
Michał Górny |