On Tue, 2020-12-29 at 11:29 +0000, Peter Stuge wrote: > Michał Górny wrote: > > > I'm sure that there are numerous cases where libressl doesn't > > > work, > > > but that's no reason to dismiss cases where it *does*. > > > > Are you asking people to put an effort into maintaining something > > that > > can't be practically installed? > > No, I'm rather asking to change the level of commitment. > > I agree completely that it's unreasonable for Gentoo (worse, 1 > person!) > to continuosly patch the entire world for libressel. > > I'm asking to stop doing that, yet still enable the choice between > openssl and libressl where that is possible without patches, even > if that's only openntpd and one other package. > > The method for that choice could of course depend on the number of > packages where it applies.
I'm pretty sure that soon enough one of Portage/Python dependencies is going to become a blocker for everything. > > > > > Did anyone gather actual numbers? > > > > $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l > > 61 > > I'm more interested in the number of packages which can use either > library without patches (like openntpd?). This may be tricky to find > out. :\ It's never that simple. Roughly speaking, there are 3 levels of incompatibility with LibreSSL: 1. Stuff that does not build against LibreSSL. 2. Stuff that builds just fine but fails at runtime in unpredictable ways (e.g. Tor mentioned today). 3. Stuff that builds and works 'fine' but ends up being crippled (e.g. doesn't support new algorithms). The first one is somewhat easy to test (e.g. via tinderbox). The other two are very hard. > > > > > > Actually, I see that someone has apparently forked libtls into > > libretls > > (the irony!) that works against OpenSSL [1]. > > To me, that proves value in the libtls API and in keeping libressl in > the tree in some capacity, even if not as an alternative to openssl. > > Maybe with a USE flag which makes it install only libtls (built from > libressl static libs), which could be one provider for a > virtual/libtls. I don't see why we would put an effort into that. I've just packaged dev-libs/libretls, and the maintenance effort in it seems really minimal. Trying to get the same result from libressl is just repeating the work. -- Best regards, Michał Górny
