Opened 4 years ago

Last modified 16 months ago

#54744 new defect

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

Reported by: ryandesign (Ryan Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: tgyurci (Teubel György), bK4gYuRo
Port: libressl openssl

Description

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.

Change History (14)

comment:1 Changed 4 years ago by 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.

comment:2 Changed 4 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Port: openssl added
Summary: libressl: Do not conflict with opensslcoexistence of libress, libressl-devel, openssl, boringssl, etc.

comment:3 Changed 4 years ago by 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?

Last edited 3 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:4 in reply to:  1 Changed 3 years ago by ryandesign (Ryan Schmidt)

Summary: coexistence of libress, libressl-devel, openssl, boringssl, etc.coexistence of libressl, libressl-devel, openssl, boringssl, etc.

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.

comment:5 Changed 3 years ago by 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?

Last edited 3 years ago by RJVB (René Bertin) (previous) (diff)

comment:6 in reply to:  5 ; Changed 3 years ago by 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"

comment:7 in reply to:  6 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by tgyurci (Teubel György)

Cc: tgyurci added

comment:9 Changed 2 years ago by 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

comment:10 in reply to:  9 Changed 2 years ago by 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 comment:ticket:55264: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.

Last edited 2 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:11 in reply to:  description Changed 2 years ago by 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.

Last edited 2 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:12 Changed 2 years ago by bK4gYuRo

Cc: bK4gYuRo added

comment:13 Changed 19 months ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 added

comment:14 Changed 16 months ago by yan12125 (Chih-Hsuan Yen)

Cc: yan12125 removed
Note: See TracTickets for help on using tickets.