Michał Górny wrote: > 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.
Nod. > > > 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. In my very next sentence (not quoted in your reply) I wrote explicitly that I do /not/ ask anyone to do so, but ask that you don't hinder it by masking libressl and also don't remove existing work potentially supporting such efforts, ie. the libressl ebuild. > I've just packaged dev-libs/libretls Thanks! That seems useful. > Trying to get the same result from libressl is just repeating the work. Maybe for you, and I'm saying that you should be able to make that choice for your systems, but also that you should not hinder others from making another choice, where that's possible and as I wrote without needing Gentoo to patch the world. Thanks a lot //Peter
