On Jan 10 11:02:46, [email protected] wrote: > Am 09.01.18 um 18:24 schrieb Perry E. Metzger: > > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary <[email protected]> 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
