Qt5 : load OpenSSL dynamically using MacPorts' port:openssl

[RJVB (René Bertin)]

As discussed on the devel ML:

Qt5 can either be linked statically to OpenSSL (current build approach), load libcrypto and libssl dynamically, or use SecureTransport.

When using OpenSSL, the details of how the crypto and ssl functions are obtained are hidden from dependent applications. IOW there are no ABI changes when Qt is built one way or the other. I don't know if this is true also when changing between OpenSSL and SecureTransport but there's a good chance this is purely internal too.

The jury is still out on the pros and cons of using SecureTransport, but I would guess that using OpenSSL means applications get security updates as soon as they become available through port:openssl, even when Apple ignores or no longer provides them.

The only reason I can see that Qt is currently linked statically to libssl and libcrypto is the fact that the dynamic load procedure doesn't consider libraries in ${prefix}/lib . The attached patch fixes that issue by inserting ${prefix}/lib into the searchpath, *after* any locations that might be set through DYLD_LIBRARY_PATH and after the application's own, embedded Contents/Frameworks location. The patch evidently needs the usual post-patch reinplace polish. It is for Qt 5.6.2 but applies to 5.8.0RC too.

I haven't checked but I think it should be trivial to patch Qt4 the same way.

[RJVB (René Bertin)]

The resulting QtNetwork dependency list:

%> otool -L /path/to/destroot/opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/QtNetwork
/path/to/destroot/opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/QtNetwork:
        /opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.8.0, current version 5.8.0)
        /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.8.0, current version 5.8.0)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.21.0)
        /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.16)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
        /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 596.15.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 673.3.0)

For comparison:

%> otool -L /opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/QtNetwork
/opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/QtNetwork:
        /opt/local/libexec/qt5/Library/Frameworks/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.7.0, current version 5.7.1)
        /opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.7.0, current version 5.7.1)
        /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.21.0)
        /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.16)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
        /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 596.15.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.17.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
>>      /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) <<
>>      /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) <<
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
        /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 673.3.0)

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Please forgive me if I am missing something, but is there a reason why one would prefer "run-time OpenSSL support" over "linked OpenSSL support" (to use the Qt description)?

[RJVB (René Bertin)]

As you said yourself, the statically linked version makes it impossible to build Qt Creator on the build bots. I understand there are licensing issues which cause this, there's even related official port syntax. There's this in the KDevelop Portfile, for instance:

#Binaries do not link to openssl, nor use the ssl backend of kdelibs4
license_noconflict  openssl

If that is no longer actual, well, then the main reason for this ticket is moot, of course.

Runtime support *should* make it a bit easier to make standalone bundled builds: just bundle libcrypto and libssl in the bundle's Contents/Frameworks and they will be used.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to RJVB:

As you said yourself, the statically linked version makes it impossible to build Qt Creator on the build bots.

I am not a lawyer, but with my very limited understanding of licensing issues, run-time OpenSSL support would not solve the license issue.
That is, if I understand the ​MacPorts ML and ​GNU FAQ correctly.

Just for the sake of completeness, here is a discussion of the ​OpenSSL and GPL conflict.

[RJVB (René Bertin)]

I have asked the question on Qt's mailing list. I do notice that the default build on Linux uses runtime loading of OpenSSL, and no distribution I know of excludes Qt or Qt Creator from binary distribution because of this. Nor the Qt company themselves, for that matter.

The GNU FAQ talks about statically vs. dynamically linked, and considers both the identical from a licensing viewpoint. That affects -openssl-linked, but shouldn't affect runtime loading because that is yet something else. It looks like OpenSSL headers are being included, though. The final link isn't clear about whether it considers linking or using dlopen+dlsym, but probably the former; it also talks about redistributing the source code and the kind of license conflict you can run into. That is a very different problem than the question whether or not MacPorts can make a binary build of something available. Finally, the post on the ML is Josh's opinion based on his interpretation of the most restrictive viewpoint.

If that opinion is law here, then we're out of luck unless we force Qt to use the system OpenSSL libraries. There might be a hole in the net though: OS X ships libssl and libcrypto, and the runtime loading process *will* find those exact libraries, even with my patch, if port:openssl isn't active:

However, as a
  special exception, the source code distributed need not include
  anything that is normally distributed (in either source or binary
  form) with the major components (compiler, kernel, and so on) of the
  operating system on which the executable runs,

It's nitpicking, but this should mean that we ought to be safe if

• Qt only declares a build dependency on port:openssl
• Qt Creator doesn't declare any dependency on port:openssl

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I am way out of my area of my expertise here.
In situations such as these, my rule of thumb is: the person who makes the final decision is the person who has to deal with the problem if things go wrong.
For MacPorts, I am honestly not sure who that would be.

[RJVB (René Bertin)]

I suppose most of us here are way out of our domain of expertise, possibly even the domain of what interests us (I know I am...) I do think that a reasonable effort to comply with rules that aren't explicit should be an adequate protection and insurance that real problems are preceded by a cease-and-desist notice requesting the take-down of binaries that shouldn't be there.

Either way, the port-check-distributable.tcl script apparently makes no difference between build- and regular dependencies on OpenSSL: they're both considered conflicting with the GPL3 license. Also, Qt Creator depends on Botan which itself depends on OpenSSL, so making QtNetwork load SSL at runtime isn't going to help.

Let me come back to the use of the headers. Sadly QtNetwork is "clever" enough to check for and use features that were introduced in OpenSSL 1.0.0, 1.0.1 and even 1.0.2 but I'd hope that at least OS X 10.11 and 10.12 ship such recent OpenSSL versions? Those OS versions that do should be able to build runtime OpenSSL support using the system headers (technically speaking, no legalese here), and in that case the exception cited above applies.

[RJVB (René Bertin)]

According to Qt's Thiagio Macieira:

> Thiago Macieira wrote:
> > Qt changed licences with 5.7: it's now GPLv2 and LGPLv3 (plus commercial).
> > GPLv3 is mentioned explicitly in the licence headers but it's implicitly
> > required by the LGPLv3 anyway.
> 
> Thanks. So you think we don't need (as in, it's safer) to list GPL3
> explicitly if we list LGPL3?

Correct.

So port:Qt5*'s license declaration should no longer mention LGPG-2.1 and can be simplified safely to

license LGPL-3

Edit: that's for Qt5 ports shipping 5.7.0 or later!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In c7a77304/macports-ports:

qt5*: add openssl variant

Some users might not want to use OpenSSL because
of licensing issues with GPL.
See ​https://lists.macports.org/pipermail/macports-dev/2017-January/thread.htmlhttps://github.com/macports/macports-ports/pull/35234
See #53369
See ​http://doc.qt.io/qt-5/qtnetwork-index.html#licenses-and-attributions

Some users may have LibreSSL installed, which conflicts with OpenSSL
and is currently incompatible with Qt.
See #51358