openssl vs. libressl

[Ryan Schmidt]

On Nov 11, 2015, at 6:15 AM, René J.V. Bertin wrote:

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

Providing choice is not a primary goal of MacPorts. Providing software that works is.

There are some situations where MacPorts offers choices. Certainly, the user can choose between installing ImageMagick or GraphicsMagick as their own personal needs dictate. But ports that declare dependencies on them use one or the other, because their APIs differ. There are the scientific ports where we offer the choice of gcc compiler, but in general that's not offered; ports build with the compiler the port and/or MacPorts has chosen, and the user is not meant to care.

When providing choices gets in the way of things working smoothly, that's a good indicator that the choice should be eliminated.


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

It seems libressl is the default ssl library in OpenBSD since one year.


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

Make libressl the default, in its default install location. Most ports will work fine with it and find it automatically. Move openssl to a different location and patch the remaining ports to use it.


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

No, I don't want to disable binaries.


> - 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`.

Variants would be a mess, and also would lead to problems when users change the variant of one port without also changing the variants of a dependency or dependent. I don't want to have variants and I don't want another portgroup.


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

I don't want base having the knowledge to automatically add a particular portgroup when a particular dependency is listed. That's just weird and unexpected.