Re: libressl vs openssl
On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary 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. There are certainly SSL libraries out there like BoringSSL that probably are better, but I am not sure it is particularly safe switching to them. Perry -- Perry E. Metzgerpe...@piermont.com
Re: libressl vs openssl
> On Jan 9, 2018, at 9:24 AM, Perry E. Metzger wrote: > > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary 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. There are certainly SSL libraries out there like BoringSSL > that probably are better, but I am not sure it is particularly safe > switching to them. Yeah, I BorgingSSL website says this: https://boringssl.googlesource.com/boringssl/ "Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.” If projects link statically against an SSL library, then BoringSSL maybe fine, but probably not as a shared library used by many packages. Blair
Re: libressl vs openssl
Am 09.01.18 um 18:24 schrieb Perry E. Metzger: On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary 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. 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, 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. The process is doable (see e.g. HardenedBSD [1], OpenBSD 5.6), but cooperation with upstream projects is probably required for some packages. all the best -g [1] https://brnrd.eu/libressl/2016-03-06/libressl-in-hardenedbsd-base-part-ii.html
Re: libressl vs openssl
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) what is the strategy with the libressl port as opposed to libressl-devel? Currently, libressl is 2.5.5 and libressl-devel is 2.6.2. I don't think upstream even considers "devel" releases in any sense, a release is a release. Is there anything else from the port's view that makes one of them "stable" and the other one "devel", or is it just a name for previous and latest? Jan
Re: libressl vs openssl
On Jan 09 12:24:22, pe...@piermont.com wrote: > On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary 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. Please read and see the following to convince yourself that it is desirable to replace OpenSSL with LibreSSL if at all possible. https://www.openbsd.org/papers/bsdcan14-libressl/index.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.youtube.com/watch?v=GnBbhXBDmwU https://www.youtube.com/watch?v=WFMYeMNCcSY https://www.tedunangst.com/flak/post/worst-common-denominator-programming https://marc.info/?l=openbsd-misc&m=139698608410938&w=2 https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse https://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf Personally, I like the socklen_t bit the most: You want to create a variable the same size as socklen_t. One fairly obvious solution would be to declare a variable of type socklen_t. That's not how OpenSSL does things, however. Instead, let's create a union of a couple different ints, call accept(), then inspect the different union members to determine which ones were overwritten by the kernel. Oh, and don't forget to check for big endian versus little endian. Jan
Re: libressl vs openssl
On Jan 09 09:40:23, bl...@orcaware.com wrote: > https://boringssl.googlesource.com/boringssl/ > > "Although BoringSSL is an open source project, it is not intended for general > use, as OpenSSL is. We don't recommend that third parties depend upon it. > Doing so is likely to be frustrating because there are no guarantees of API > or ABI stability.” > > If projects link statically against an SSL library, then BoringSSL maybe > fine, but probably not as a shared library used by many packages. As opposed to a static library used by many packages?
Re: libressl vs openssl
On Jan 10 11:02:46, neum...@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 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
Re: libressl vs openssl
On Jan 10, 2018, at 14:49, Jan Stary wrote: > On Jan 09 09:40:23, Blair Zajac wrote: >> https://boringssl.googlesource.com/boringssl/ >> >> "Although BoringSSL is an open source project, it is not intended for >> general use, as OpenSSL is. We don't recommend that third parties depend >> upon it. Doing so is likely to be frustrating because there are no >> guarantees of API or ABI stability.” >> >> If projects link statically against an SSL library, then BoringSSL maybe >> fine, but probably not as a shared library used by many packages. > > As opposed to a static library used by many packages? Ideally, ports should not link with static libraries; they should link with dynamic libraries. That way they receive bug fixes as soon as the port that provides the library is updated.
Re: libressl vs openssl
On Jan 10, 2018, at 06:33, Jan Stary wrote: > what is the strategy with the libressl port as opposed to libressl-devel? > Currently, libressl is 2.5.5 and libressl-devel is 2.6.2. > > I don't think upstream even considers "devel" releases in any sense, > a release is a release. Is there anything else from the port's view > that makes one of them "stable" and the other one "devel", > or is it just a name for previous and latest? A -devel port is a place where a port maintainer can try things out before making them available to the larger audience that uses the stable port. Those things might include a newer version of the software, different configure or build flags, a different build system, or anything else. I'm not sure what Jeremy's specific strategy is with the libressl-devel port, but at the moment it seems to be just a newer version with no other changes. The request to update the libressl port to a newer version is here: https://trac.macports.org/ticket/55264
Re: libressl vs openssl
On Wed, Jan 10, 2018 at 9:45 PM, Jan Stary wrote: > On Jan 09 12:24:22, pe...@piermont.com wrote: >> On Mon, 8 Jan 2018 18:47:14 +0100 Jan Stary 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. > > Please read and see the following to convince yourself that > it is desirable to replace OpenSSL with LibreSSL if at all possible. Speaking as a port maintainer (who has to go update his port sometime) upstream should be the ones doing as much as possible, and we should not have to patch that much. OpenSSL has dramatically improved their code quality over the past few years. > > https://www.openbsd.org/papers/bsdcan14-libressl/index.html > https://www.openbsd.org/papers/eurobsdcon2014-libressl.html > https://www.youtube.com/watch?v=GnBbhXBDmwU > https://www.youtube.com/watch?v=WFMYeMNCcSY > https://www.tedunangst.com/flak/post/worst-common-denominator-programming > https://marc.info/?l=openbsd-misc&m=139698608410938&w=2 > https://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse > https://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf > > Personally, I like the socklen_t bit the most: > > You want to create a variable the same size as socklen_t. One fairly > obvious solution would be to declare a variable of type socklen_t. > That's not how OpenSSL does things, however. Instead, let's create > a union of a couple different ints, call accept(), then inspect the > different union members to determine which ones were overwritten by the > kernel. Oh, and don't forget to check for big endian versus little endian. > > Jan > > -- "Man is born free, but everywhere he is in chains". --Rousseau
Re: libressl vs openssl
On Jan 11 07:07:42, ryandes...@macports.org wrote: > > On Jan 10, 2018, at 14:49, Jan Stary wrote: > > > On Jan 09 09:40:23, Blair Zajac wrote: > >> https://boringssl.googlesource.com/boringssl/ > >> > >> "Although BoringSSL is an open source project, it is not intended for > >> general use, as OpenSSL is. We don't recommend that third parties depend > >> upon it. Doing so is likely to be frustrating because there are no > >> guarantees of API or ABI stability.” > >> > >> If projects link statically against an SSL library, then BoringSSL maybe > >> fine, but probably not as a shared library used by many packages. > > > > As opposed to a static library used by many packages? > > Ideally, ports should not link with static libraries; they should link with > dynamic libraries. That way they receive bug fixes as soon as the port that > provides the library is updated. Yes. But my note was regrding the suitabilty of LibreSSL/BoringSSL as an alternative to OpenSSL - that has nothing to do with static/shared - you can say the same about each of them.
