[MacPorts] #54744: coexistence of libressl, libressl-devel, openssl, boringssl, etc.
MacPorts
noreply at macports.org
Thu Jan 11 17:32:13 UTC 2018
#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 RJVB):
I'd vote against deprecating openssl or anything that looks like it - 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). 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. 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.
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.
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?
--
Ticket URL: <https://trac.macports.org/ticket/54744#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list