[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.

[MacPorts]

#54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.
-------------------------------+----------------------
  Reporter:  ryandesign        |      Owner:  jeremyhu
      Type:  defect            |     Status:  new
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:                    |   Keywords:
      Port:  libressl openssl  |
-------------------------------+----------------------

Comment (by jeremyhu):

 Replying to [comment:4 ryandesign]:
 > The user can receive binaries built on our buildbot with a stable
 version of a library and use them with the development version of the
 library on their system, assuming the library's `install_name` hasn't
 changed.

 Exactly, and since ffmpeg and ffmpeg-devel almost always have different
 dylib ids, ffmpeg-devel is not a drop in binary compatible replacement for
 ffmpeg.  Thus, it is the same situation as libressl, libressl-devel, and
 openssl.

 > for the hopefully short duration of time until the stable version of the
 port is updated to the new version that has that same new major library
 version.

 This is actually the norm for ffmpeg.  It's expected that this is the case
 long-term and a rarity that they dylib ids are the same.

 > The libressl/openssl situation is completely different because they
 always have and always will have completely different major library
 versions and therefore `install_name`s and are therefore never drop-in
 replacements for one another.

 Yes, that is true, but I don't think it's right to say that we need to
 address this for the specific case of libressl vs openssl when it would be
 better to come up with a more general solution that applies to binary-
 incompatible alternative API providers.

 > the ports that are compatible with libressl should specify a dependency
 on `path:lib/libssl.dylib:libressl` (to continue to allow users to use
 libressl-devel instead if desired);

 libressl-devel will almost always be binary incompatible with libressl,
 just as ffmpeg-devel is almost always binary incompatible with ffmpeg.

 their revisions should be increased so that they rebuild with the correct
 libssl library version and `install_name`; openssl should be changed to
 install into a different location (like ${prefix}/lib/openssl and
 ${prefix}/include/openssl as you suggested, or even just
 `--prefix=${prefix}/libexec/openssl`) so that it does not conflict with
 libressl; and the remaining ports that require openssl should change their
 dependencies to `port:openssl` and have their revisions bumped to find
 openssl in its new location (probably along with portfile changes to help
 them find openssl in the new location).

 I'd prefer to have all alternative implementations follow the same
 installation convention instead of having one be in $prefix/lib and the
 rest in $prefix/lib/$name.

 > I don't see a boringssl port in MacPorts yet. Is there some need it
 meets that libressl would not? I'd like to keep things simple, and
 simplest would be not to add another ssl library.

 It would possibly be desired if anyone decided to get chromium working,
 but I see no need for it.

 I don't see a good option that doesn't involve a major change to base of
 an ssl PortGroup to manage this.

 Replying to [comment:5 RJVB]:
 > I'd vote against deprecating openssl or anything that looks like it for
 that same reason - I don't think we can get around it as long as it's the
 de-facto SSL provider on Linux (= the platform for which so many of the
 ports in MacPorts are written).

 Really?  libressl is default/only on macOS, TrueOS, OpenBSD, FreeBSD,
 NetBSD, and some Linux distros.  I haven't seen much in the way of support
 for OpenSSL and wouldn't be surprised if more Linus distress eventually
 moved over to Libressl.

 > It doesn't really matter how technically inferior it is; as long as it's
 good enough to do the job it's probably the more practical and thus the
 better solution.

 On the contrary, when it comes to security and privacy, it is *very*
 important to have a technically superior implementation.  There have been
 significantly more CVEs reported against OpenSSL than against Libressl
 since the fork, and most (all?) of the ones impacting Libressl were from
 pre-fork code that also impacted OpenSSL.

 > I'm not interested in having to jump through all kinds of hoops to get a
 theoretically better SSL implementation while most of the software I work
 with was conceived to use OpenSSL and the majority of "my" ports depend on
 (or are dependencies of) Qt5 which is incompatible with LibreSSL.

 I highly suspect it's trivial to fix QT5 for work with libressl given that
 QT5 almost certainly works fine on one of the many other platforms that
 also use Libressl as the only/default implementation.

 > As expressed on another ticket, I'd vote for an approach with a build
 variant coupled with a mechanism to indicate incompatibility with either
 one of the alternative *SSL ports - probably via a PortGroup just because
 that's more practical to maintain than an implementation as a feature in
 "base". In fact I set out designing such an SSL PG a bit over 2y ago but
 gave up when I came to the conclusion that LibreSSL wasn't such a viable
 alternative to OpenSSL in practice.

 Do you have that WIP anywhere?

 What made you think Libressl wasn't viable?  I'm shocked that many people
 still cling to OpenSSL after the repeated security debacles they have
 continued to face after heartbleed.

 > BTW, what do we know about mixing OpenSSL and LibreSSL in the address
 space of a single application, provided that no data is passed between
 implementations? IOW, can a Qt5 application (say, QupZilla) that uses
 OpenSSL via Qt APIs also use non-Qt libraries built to use LibreSSL (say,
 libcurl), or is that just asking for trouble?

 Should work just fine.  The API isn't objective-c, so the 2 level
 namespace should let things "just work"

--
Ticket URL: <https://trac.macports.org/ticket/54744#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS