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