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. > A side effect of this approach is that users will be tricked into using > LibreSSL, only to discover that they eventually have to transition > their systems back. I believe I'm asking for the opposite. I think it's fine to say that libressl has to be a deliberate choice rather than a default. > > 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. :\ > > > > B. It brings its own TLS API, a unique feature which by itself > > > > warrants the package. > > > > > > ...which by itself has no future > > > > That's arrogant and silly coming from anywhere but upstream. > > > > You can argue that you will never use the API in your TLS programs, > > but even then that says really nothing about the API provider itself. > > That's my opinion and I have a right to have it without being insulted. You absolutely have a right to your opinion but you stated it as fact, that made me react so strongly. > I don't dispute whether it's good. I dispute whether tightly binding > it to a problematic LibreSSL is a good idea. I agree with this, but only in cases where libressl is indeed problematic. I can think of systems where it isn't, there the choice is a good thing. > 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. Note: I'm not at all expecting anyone to do such work for me, I just don't want it to become impossible (libressl mask) or any existing effort supporting something like the above to be sunset. Does that make sense? Thanks! //Peter
