| 1 |
On Mon, 2020-12-28 at 09:56 +0100, Michał Górny wrote: |
| 2 |
> TL;DR: is there really a point in continuing the never-ending always- |
| 3 |
> regressing struggle towards supporting LibreSSL in Gentoo? |
| 4 |
|
| 5 |
Since the discussion has grown quite, let's summarize what was said so |
| 6 |
far. |
| 7 |
|
| 8 |
It seems that all respondents so far unanimously agree that the current |
| 9 |
state of libressl is suboptimal. Unless I've missed something, we also |
| 10 |
all agree that developers shouldn't put additional work to continue |
| 11 |
supporting it in their packages. What we don't seem to agree on is how |
| 12 |
we should proceed with libressl itself and its existing support |
| 13 |
in the future. |
| 14 |
|
| 15 |
|
| 16 |
I think the key points right now are that: |
| 17 |
|
| 18 |
1. Users shouldn't take switching between OpenSSL and LibreSSL lightly. |
| 19 |
|
| 20 |
2. We should probably discourage users from using LibreSSL on new |
| 21 |
systems for the time being. |
| 22 |
|
| 23 |
3. We need to establish the way forward and inform the users about it. |
| 24 |
|
| 25 |
4. We should probably wait for USE=bindist updates (due to patents |
| 26 |
expiring) and dev-libs/libretls support (whenever possible) before |
| 27 |
doing anything. |
| 28 |
|
| 29 |
|
| 30 |
In my opinion, the bare minimum we should do is to mask the libressl |
| 31 |
flag. This should ensure that users do not take it lightly, and can |
| 32 |
get an appropriate warning (from the mask message) if they really wish |
| 33 |
to switch. The downside of that is that it will implicitly force |
| 34 |
switching back existing systems, unless sysadmins take care to unmask |
| 35 |
the flag first. I think this can be solved by issuing a news item |
| 36 |
in advance. |
| 37 |
|
| 38 |
However, if we stop proactive downstream patching of LibreSSL support |
| 39 |
(which we seem to agree on), the existing LibreSSL systems may become |
| 40 |
unmaintainable (I can already imagine the super-unreadable Portage slot |
| 41 |
conflict messages). A reasonable compromise could be to maintain |
| 42 |
the necessary patching in libressl overlay. If LibreSSL team (or |
| 43 |
anybody else) is willing to take care of that, we should mention that |
| 44 |
in the news item. |
| 45 |
|
| 46 |
The fate of LibreSSL is a congestion point here. While I don't mind |
| 47 |
keeping it by itself, I don't think it's prudent to keep it if it |
| 48 |
becomes practically impossible to use it, and what I'd really like to |
| 49 |
avoid is giving users false hope. The news item should clearly |
| 50 |
indicate what's going to happen and at least approximately when. |
| 51 |
|
| 52 |
|
| 53 |
I think the three main ways forward from here would be to either: |
| 54 |
|
| 55 |
1. Keep LibreSSL for indefinite time (possibly masked) but indicate |
| 56 |
that using it will become more and more difficult. Users will either |
| 57 |
have to use libressl overlay or local hacks to avoid conflicts with |
| 58 |
packages that do not support it. |
| 59 |
|
| 60 |
2. Eventually move LibreSSL to libressl overlay. I think this is |
| 61 |
the best option if overlay is going to be actively maintained. It also |
| 62 |
opens other interesting options, such as providing a dev-libs/openssl |
| 63 |
meta-replacement to avoid the added complexity of USE=libressl |
| 64 |
while providing clean subslot rebuilds. |
| 65 |
|
| 66 |
3. Eventually remove LibreSSL. |
| 67 |
|
| 68 |
|
| 69 |
I think that we should first reach an agreement on how to proceed, then |
| 70 |
start preparing the news item with clear deadlines for each step. |
| 71 |
|
| 72 |
-- |
| 73 |
Best regards, |
| 74 |
Michał Górny |
Archives