LibreSSL and OpenSSL and *SSL

[Jan Stary]

On Feb 16 19:36:56, notifications at github.com wrote:
> The two versions are not actually completely compatible

true

> and it is not clear that we should wish to support
> the use of libressl in place of openssl

Now that the base OS uses LibreSSL by default, I believe we should.
Not only should we wish to support it, we should actively ask upstream
to support it, or why they don't.

While it's true that the two version are not completely compatible,
in e.g. the opusfile port that started this, the incompatibilty
is completely artificial.

Opus is an audio codec - why does it need to link with -lssl?
It wants to play remote audio files, and for that it might need
to make a secure connection. That's a very basic thing which should
not depend on this or that version of this or that implementation.

The noncompatibility is tests for OPENSSL_VERSION_NUMBER<0x10002000L etc
that already assume that OPENSSL is the only implementation. The patch
is trivial: add defined(LIBRESSL_VERSION_NUMBER) in 11 places.

Obviously, I have not studied all the ports that depend on OpenSSL now,
and I don't doubt that many of them depend on *SSL in a nontrvial way.
But I would be willing to bet that in a lot of cases, the noncompatibilty
between versions is similarly artificial: upstream simply did not take
LibreSSL into consideration (yet).

> when the upstream does not support it.
> There's no actual benefit to it
> (I know that will be controversial but it's my firm opinion),

Right.

> so if we start making every port handle both it means a bunch of
> support work to make something upstream doesn't support possible
> when there's no good reason to want it in the first place.

Riiiight.

On Feb 16 19:40:29, notifications at github.com wrote:
> I mean, say your port uses OpenSSL. Jan inserts a bunch of patches
> to make it support LibreSSL mostly because he believes that it's better.

Yes I do; you apparently don't; that's life.
More importantly, LibreSSL is the default on MacOS now.

> You want to update your port and the patches no longer work.

Example?

> You didn't want the patches in the first place and now it's your job
> to update them anyway, and then to test that they work.
> This is added work for maintainers,

Yes.

> but for no benefit.

Riiiiight. Let's stay with OpenSSL forever. It's perfect.

On Feb 16 19:42:24, notifications at github.com wrote:
> There is benefit for people who would prefer to use LibreSSL. It's a good medium-term or long-term goal to eliminate the LibreSSL/OpenSSL conflict and require ports to explicitly adopt LibreSSL.

Exactly.

> Of course I would object to any extensive patching for LibreSSL compatibility, but this hardly qualifies.

Has anyone tried to patch a port that uses OpenSSL in some
complicated ways to work with LibreSSL as well? How hard was it?
(It's a honest question - not that would push other maintainers into it.)

On Feb 16 20:15:04, notifications at github.com wrote:
> I don't see why requiring ports to adopt LibreSSL
> should be a goal of any sort. It's not a win.
> OpenSSL was once undersupported because they didn't have funds
> to have full time staff doing development and maintenance.
> That ended a long time ago after Heartbleed.
> The project is now fully funded and has excellent people working on it.

Now we get to the real thing: LibreSSL is better.

For those who actually care: please do watch the original
talks and slides about why LibreSSL even exists:

https://www.youtube.com/watch?v=GnBbhXBDmwU
https://www.openbsd.org/papers/bsdcan14-libressl/

https://www.youtube.com/watch?v=WFMYeMNCcSY
https://www.openbsd.org/papers/eurobsdcon2014-libressl.html

Yes, that's almost four years ago. So how much of the
attrocities mentioned in the above have been fixed?
Does it still use its own OPENSSL_malloc() that never frees?
Does it still use its own OPENSSL_strfoo() that is almost,
but not quite, indetical to the usual, well defined strfoo(3)?
Has the depth of the #ifdef/#ifndef maze dropped from 17?
Are the security vulnerabilities still rotting in the bug DB for years?
Is it still impossible to enter the codebase from outside
without untangling it for weeks?

The LibreSSL developers state explicitly that heartbleed
was not why they started their fork. It was things like these.
https://www.tedunangst.com/flak/post/origins-of-libressl

On Feb 16 12:55:20, notifications at github.com wrote:
> jmroot approved this pull request.
> Looks reasonable. In the absence of any objection from the maintainer
> I'm just going to merge.

On Feb 16 11:13:09, notifications at github.com wrote:
> @dbevans Can you offer your opinion here?

I would also be interested in David's opinion; there are
no comments from him (= maintainer) in the orginal thread.

	Jan