Re: [gentoo-dev] libressl status

[hasufell]

On 04/07/2015 12:06 AM, Paul B. Henson wrote:
>> From: hasufell
>> Sent: Sunday, April 05, 2015 4:34 AM
>>
>> However, openntpd still compiles with openssl.
>
> Well, the current stable openntpd in portage compiles with openssl but that's not surprising as it is ancient and predates libressl :). The current unstable openntpd actually has no ssl dependencies and needs neither openssl nor libressl to compile and function. It is the most recent upstream portable release that added an optional dependency on libressl for tls constraint functionality, that version is not yet in portage. It will work without libressl just as well as the current unstable openntpd does, you just won't have access to the new feature. So it's not really critical, but at some point it would be nice to get it working one way or the other.

I was actually talking about the latest openntpd (5.7p4), but you are
correct... there is no linkage to openssl. It compiles without the feature.

So, users who want that feature have to:
a) switch to libressl
b) provide a patch to openssl upstream to include the feature
c) maybe provide some other compatibility patch to openntpd upstream?

This is the what improves the linux ecosystem, IMO. Downstream hackery
does not.

>> By that you are effectively forking libressl and causing a huge mess
>> downstream for both developers and users.
>
> What are the downsides of the approach pkgsrc is tentatively taking, where there are no modifications to libressl but the libraries are installed in an alternative location? Packages that require libressl can just use the appropriate linker options to find those libraries rather than the openssl ones?
>

Because it breaks FHS. If you do embedded stuff or binpkg things, you'll
probably do that on purpose. But that shouldn't be default, unless you
build a proper abstraction layer to allow this system-wide, not just for
one package. And then you already want to install NixOS, not gentoo...
again: with the price of breaking FHS completely, which is not trivial.

In addition, it will require patches to a lot of packages. I currently
don't see a good reason to go through that pain. And I'm one of the few
who actually work on those ebuilds, not just talk about them.

>> worse. This is something that has to be resolved upstream. If they don't
>> cooperate long-term, then their fork will just die out for sure (and for
>> good). However, I currently don't see strong signs for that.
>
> I don't think their fork will ever die; even if no one outside of openbsd uses the portable version, it is now the official ssl provider for openbsd and I am sure will continue to be used by them as well as the portable versions of any of their other applications such as openntpd...
>

Well, if they really screw up openntpd for openssl users, then I expect
there will be forks/alternatives. I can't really say how critical the
feature is, but if it's a deal-breaker, then something has to happen.
Our political voice in that situation would come from NOT fixing it
downstream, but saying "no, neither openntpd nor libressl will get in
here in that shape". Given that we've already been contacted to
endorse/fund/support libressl, I guess we can try to play that card in
worst case. But again: that's all weather forecast.


On another note, the concerns of beaking proprietary software that
bundles a crapload of broken and vulnerable libraries... is pretty thin
IMO. I'm not even sure if we as a source distro should care that much
about this use case to an extent that we break things at other places,
just to support it. And, I haven't even seen a list of packages that
would be affected. Worst case there will be an elog about it.


I'd like to stick to actual problems for now.