coexistence of libressl, libressl-devel, openssl, boringssl, etc.

[ryandesign (Ryan Carsten Schmidt)]

Contrary to what has been implemented in MacPorts thus far, libressl is not a drop-in replacement for openssl. (See e.g. #54669 and #54688.)

To fix this, libressl should be modified to install files to different locations than openssl; libressl and openssl should then no longer be marked as conflicting; and all ports that currently depend on openssl via a path:-style dependency should be changed to have openssl and libressl variants to choose which library to use.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes, they have different dylib ids and are ABI incompatible (just like different versions of ffmpeg for example). The problem here is no different than the issues encountered between using ffmpeg and ffmpeg-devel.

Any change here to libressl/libressl-devel should be mirrored by similar changes in openssl.

Furthermore, I suggest that we switch all dependents over to using libressl instead of openssl as the default. There's no reason for us to continue to push an inferior implementation onto our users. I've been using libressl exclusively for years now.

[jeremyhu (Jeremy Huddleston Sequoia)]

The same could apply to boringssl as well.

I propose installing with --libdir=${prefix}/lib/${name} --includedir=${prefix}/include/${name}.

The binaries could be suffixed with a port select mechanism.

dependents would need to specify PKG_CONFIG_PATH. We could probably setup a PortGroup to manage that (as well as options for specifying which variants are supported / default).

How should we handle the man pages?

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu:

Yes, they have different dylib ids and are ABI incompatible (just like different versions of ffmpeg for example). The problem here is no different than the issues encountered between using ffmpeg and ffmpeg-devel.

That's a completely different situation, in most cases. The assumption with -devel ports is that it's the development version of the software and it has features and bug fixes not present in the stable version but is otherwise a drop-in replacement for the stable version. 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.

In some cases, the development version may have a newer major library version number and thus a new install_name, which breaks the ability to use precompiled binaries, but only 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.

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

Furthermore, I suggest that we switch all dependents over to using libressl instead of openssl as the default. There's no reason for us to continue to push an inferior implementation onto our users. I've been using libressl exclusively for years now.

In principle I have no problem with deprecating openssl in MacPorts and keeping it around only for the benefit of software that is not compatible with libressl. In that case 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); 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).

Replying to jeremyhu:

The same could apply to boringssl as well.

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.

[RJVB (René Bertin)]

I'd like to keep things simple, and simplest would be not to add another ssl library.

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). 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?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to 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_names 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 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"

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jeremyhu:

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"

Also, we'e been shipping macOS like this for years with libressl + OpenSSL and even longer with multiple versions of OpenSSL.

[jamie-arcc (Michael James "Jamie" Schnaitter)]

bump

Has there been any more progress towards a solution for this? It would definitely be useful to be able to keep LibreSSL up to date, which is currently being held by this issue in #55264

[TP75]

Replying to jamie-arcc:

bump

Has there been any more progress towards a solution for this? It would definitely be useful to be able to keep LibreSSL up to date, which is currently being held by this issue in #55264

My commentary there was ​https://trac.macports.org/ticket/55264#comment:21

Please be aware there is a port libressl-devel available in MacPorts for some time already. To my knowledge there is a sufficient amount of ports which compile nicely with libressl-devel @2.8.1 and IMHO one should give it a try before mainly complaining. Notwithstanding any security discussions there is always the chance for everybody for ​contributing to MacPorts or to provide some ​portfile development in support of the volunteers and maintainers.

You may find the pull-request libressl-devel: update to 2.8.2 ​#3056 as my first contribution.

[TP75]

Replying to ryandesign:

Contrary to what has been implemented in MacPorts thus far, libressl is not a drop-in replacement for openssl. (See e.g. #54669 and #54688.)

You may have a look at comment:ticket:54688:10 as certainly the current nodejs11 @11.2.0 with libressl-devel @2.8.1 is a successful install.

[neverpanic (Clemens Lang)]

Re-assigning to new libressl maintainer.

[Zweihorn (@Zweihorn)]

Hi,

I just want to express my sincere gratitude to the new maintainer of both libressl and libressl-devel.

Lacking some open commitment from myself to help the former maintainers, I was dependig on just bumping myself my local port defintion for libressl for years, unfortunately. However, the current updates for libressl and libressl-devel in parallel look very promising.

I highly appreciate the curent reasonable approach to meet the LibreSSL upstream update cicle in an applicable way.

I would like to understand this approach as:

• libressl at 3.6.x until the 3.8 or newer comes around (then itself switching to 3.7.x) or 3.6 becomes EOL
• libressl-devel at 3.7.x until the new development 3.8 or newer version comes around

IMO this fits.

Last not least would like to express my strong support for this port. For certain reasons I am a long standing user of LibreSSL on all my Mac OS X / macOS platforms for years and will continue using it.

Thank you very much. Keep on the good work and prosper.

[artkiver (グレェ)]

Replying to Zweihorn:

Thank you for the kind words, and you are most welcome; admittedly, I also would be remiss in not also thanking neverpanic for volunteering to be co-maintainer.

Regarding your inquiry as far as the differentiation between libressl and libressl-devel, it should be the case that libressl-devel follows releases described as Development from the LibreSSL project (currently 3.7.0) though we can probably expect LibreSSL 3.7.1 (as a "stable" release, and thus better suited to the libressl MacPort than libressl-devel) at some point (indeed there have been hints of such things to address some issues on the LibreSSL mailing list), which will be merged into the MacPort whenever I see a release announcement and do local testing and submit a PR.

Based on past release versions from the upstream project, we probably won't see 3.8.x LibreSSL variants until OpenBSD starts tagging their branches for version 7.3 of their OS release probably? That is just an educated guess on my part though, despite doing volunteer editing for undeadly.org, I am not an OpenBSD committer and more just an assiduous observer of its development and related projects.

There was an instance where both libressl and libressl-devel were at 3.6.1, mostly thanks to neverpanic's suggestion so as to iron out an issue where I had incorrectly submitted a PR for a non Development release which was merged for libressl-devel, but I think as things presently stand, it is consistent with the upstream project and hopefully moving forward we will endeavor to maintain that consistency!

I've attempted to do a little bit of sprucing up of some other related ports as well e.g. there was a libevent patch with some upstream changes not yet in a versioned release that improved compatibility with LibreSSL which I tested and they were merged successfully (​https://github.com/macports/macports-ports/pull/16681), though someone else submitted that PR. I submitted a PR for xar, which made it a bit more LibreSSL friendly by using the dynamic library which got merged as well (​https://github.com/macports/macports-ports/pull/16977).

Currently, I have one uncommitted PR for rpki-client (​https://github.com/macports/macports-ports/pull/16987) because I am pretty sure there there must be a better way to modify the Portfile, but I figured submitting a PR was at least one method to try to get some other eyeballs on it. Essentially, rpki-client will function with LibreSSL without issues; however if referencing the dynamic library, it *can* use OpenSSL as the previous version Portfile defaults reference, but only if LibreTLS is also a dependency. There is doubtlessly a better way to handle that than my attempt, but I figured better to submit some attempt and get additional input than to ignore it completely? I have been contemplating other ways to handle that, but haven't had a lot of time to give it more attention with the holidays. Honestly, it would be easier to submit a Portfile which requires LibreSSL instead of the dynamic library in that instance, but I didn't want to upset previous rpki-client users who were probably already accustomed to the OpenSSL and LibreTLS dependencies by leaving them out in the cold entirely.

There are probably other rough edges too which hopefully in time and with sufficient cooperation we can smooth out as well. As for me, I mostly started taking a took at at such things when a JWZ blogpost brought to my attention an issue with an old version of LibreSSL and Let's Encrypt last year.

Thankfully, the version of macOS's LibreSSL has been updated with Ventura, though macOS versions prior to Ventura were shipping with a version of LibreSSL which was about four years old, so it seemed worthwhile to try to keep the MacPorts' version a little more up to date.

As it currently stands, both libressl and libressl-devel are approximately 9 months ahead of the version shipping with Ventura, and I imagine that disparity will probably continue just given the nature of the upstream projects' release cycles as well as the nebulous nature of the whims of Apple's attention to their CLI tools.

It's certainly my intention to continue to focus time and attention on keeping the ports as current as seems possible and I am guessing neverpanic shares similar sentiments. Thank you for noticing!

Hi,

I just want to express my sincere gratitude to the new maintainer of both libressl and libressl-devel.

Lacking some open commitment from myself to help the former maintainers, I was dependig on just bumping myself my local port defintion for libressl for years, unfortunately. However, the current updates for libressl and libressl-devel in parallel look very promising.

I highly appreciate the curent reasonable approach to meet the LibreSSL upstream update cicle in an applicable way.

I would like to understand this approach as:

• libressl at 3.6.x until the 3.8 or newer comes around (then itself switching to 3.7.x) or 3.6 becomes EOL
• libressl-devel at 3.7.x until the new development 3.8 or newer version comes around

IMO this fits.

Last not least would like to express my strong support for this port. For certain reasons I am a long standing user of LibreSSL on all my Mac OS X / macOS platforms for years and will continue using it.

Thank you very much. Keep on the good work and prosper.