libressl vs openssl

[Jan Stary]

On Jan 10 11:02:46, neumann at wu.ac.at wrote:
> Am 09.01.18 um 18:24 schrieb Perry E. Metzger:
> > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary <hans at stare.cz> wrote:
> > > Hi Jeremy,
> > > 
> > > > On Sat, Dec 02, 2017 at 06:03:17AM -0800, Jeremy Huddleston
> > > > Sequoia wrote:
> > > > > There are some things that I want to do to the port (and
> > > > > OpenSSL)
> > > It would be very nice if all ports currently depending on openssl
> > > would build against libressl, and we could get rid of openssl
> > > in favor of the way-superior libressl (until Apple replaces
> > > it system wide. ha ha ha.)
> > I'm not sure I agree with the claim that libressl is necessarily
> > better.
> i would as well be cautions with the term "superior", at least when the
> criteria are not clear.

So here is a few, as a start:

Wraps malloc() -- and every other normal C function -- in its
VERYOWNBUGGY_malloc() that never frees, thus sabotaging any
memory-exploit mitigations the OS migth be doing?

Has its own snprintf() and memcmp() etc, with an _almost_ identical
interface and return values, but not quite?

Has its own broken random generator?

Nests #ifdefs to depth 17?

Has NO_OLD_ASN1 and NO_ASN1_OLD compile options
doing different things?

Defines a union of a couple different ints, calls accept(),
then inspect the different union members to determine which ones were
overwritten by the kernel, to find out what the size of socklen_t is?

Contains tens of thousands of lines of dead code
to support VMS or MS Visual C 1.52?

> In the past i have provided support for OpenSSL 1.0.* and 1.1.* and
> LibreSSL 2.6.3 and 2.6.4 for non-trivial projects , and from my experience
> this is not a simple drop-in replacement in general.
> One pain is that OpenSSL changed some calls between 1.0 and 1.1,

Could you please elaborate on the technical details?
Or point to some write-up on that?

> and another one is that LibreSSL claims to be OpenSSL 2.*
> (via |OPENSSL_VERSION_NUMBER|)
> which confuses source code that has to compare for version numbers
> for the above reasons.

Comparing a version number is not the hard part, right?
For example, this is how we currently unconfuse libevent:
https://github.com/macports/macports-ports/blob/master/devel/libevent/files/patch-libressl.diff

> The process is doable (see e.g. HardenedBSD [1], OpenBSD 5.6),

Well, OpenBSD is where it came from.

> but cooperation with upstream projects
> is probably required for some packages.

Definitely; I am going through the ports that depend on SSL
trying to sort it out at least in the ports I use. Some work
just fine with LibreSSL, some need patches, some just need to
be unconfused about the version.


	Jan