openssl vs. libressl

[René J.V. Bertin]

On Wednesday November 11 2015 05:27:49 Ryan Schmidt wrote:

>If we don't want to switch to libressl as a default, then I don't know why libressl is in MacPorts.

To provide choice. Apart from the fact that the ssl ports can't be swapped without rebuilding all dependents, the only thing that doesn't work properly in the current situation is the use of binary packages. I personally don't like the idea of making libressl the default as long as this hasn't been tested more in depth (are there Linux distros out there which do this?).

One of my original main reasons to install MacPorts was support productivity on things other than MacPorts itself, and I think that's probably the case for a majority of users. If true, that imposes a rather conservative approach.

As I've said before, I fear that patching in a way to support parallel installation of openssl and libressl is going to be a quite maintenance-heavy endeavour, as I doubt either of the projects nor many of their dependents have been designed with that kind of usage in mind.

Meanwhile, there are 2 solutions to avoiding the binary package issue mentioned above that do not involve parallel installation of the ssl ports:
- disallow binary packages for all direct dependents of openssl (or libressl, should it become the default at some point). This evidently isn't ideal, as it puts all the cost on all users; *big* ports like Qt5 are among the dependents.
- incite port devs to use an ssl PortGroup that provides the appropriate dependency but that also provides protection against installing binary packages built against the wrong ssl port. I've done something similar in my qt5-kde PortGroup: it involves introducing a variant that is either set default when a port expresses a preference, or when the user expressed a preference by installing a "not-the-default" alternative (say qt5-kde instead of qt5-mac or libressl instead of openssl) or by selecting the variant explicitly. Either way, the variant controls the path-style dep: +openssl would use path:lib/libssl.dylib:openssl and +libressl would use path:lib/libssl.dylib:libressl . Expressing a preference would be setting a variable before including the PortGroup, e.g. `set ssl.prefer_libressl` or `ssl.preferred_implementation libressl`.

In that approach, and as far as I can tell, that means that
- when a port expresses a preference it inherits a default variant meaning its binary package will be built against and with a registered dependency on the corresponding ssl port
- when a user made the opposite choice (say libressl instead of openssl), doing `port install curl` (for example) will translate to `port install curl +libressl` which means s/he won't benefit of binary packages for curl when curl has not expressed a preference for libressl.
- thus, I expect all premises of the reproducible-builds principle to hold.

I can whip up a draft to illustrate this if you want.

The good thing I see with this approach is that it puts most of the effort on the plate of the joint openssl and libressl maintainers, requiring only a small modification of the maintainers of other ports (remove an entry from depends_lib, adding a PortGroup statement). Ports that fail to make this modification will of course cause errors on user systems, which is not ideal at all but at least the underlying issue should be relatively easy to diagnose and even more so to fix.
It's even *conceivable* to modify "base" to include the ssl PortGroup automatically when openssl or libressl appears in a depends statement. That might not even be such a wild idea for a central port like the one providing ssl.

R.