[Bug 216781] net/qt5-network: fix build with libressl-devel

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216781

--- Comment #1 from matthew at reztek.cz ---
Created attachment 180112
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180112&action=edit
fix qt5-network with libressl

The quick change to make it compile is not the ideal change. Better would be to
re-implement the curve control code in a more portable way. The issue is not
the ability to set curves but the method for doing so; the SSL_CTRL_SET_CURVES
"convenience" macro only exists in OpenSSL. The BoringSSL porting guide says
use of that macro should be replaced with the function SSL_CTX_set1_curves,
which is what the macro would have called anyway. That should be fully portable
as that function exists in OpenSSL, and LibreSSL has a macro of the same name
to call their function SSL_CTX_set1_groups which serves the same purpose.
Unfortunately, Qt complicates matters by loading the libraries and resolving
symbols itself, so that macro doesn't help us for LibreSSL and we still need a
separate code path, but at least we can use one path for both OpenSSL and
BoringSSL so we don't need three cases.

While implementing a proper solution to this issue, I was forced to dig into
the dynamic loading of the SSL libraries, something I suspected was not working
properly. What I found is that we have a patch meant to use the full path to
find the correct OpenSSL libs first without searching many paths in Linux's
preferred order. However, there is a mistake in that patch so it tried to open
/usr/local/libssl.so and /usr/local/libcrypto.so instead of
/usr/local/lib/libssl.so and /usr/local/lib/libcrypto.so. Of course those opens
fail, so it would then proceed to go searching directories, and since it looks
in /usr/lib before /usr/local/lib it picked up base OpenSSL and thus couldn't
resolve numerous symbols. Even if the path in that patch were correct, the
patch would still be incorrect, because LOCALBASE is not always /usr/local, and
the correct SSL libs are not necessarily from ports (one could build against
base OpenSSL). This has been corrected by using OPENSSLLIB which is the full
path to the libs for the version of Open/LibreSSL we are compiling against, be
it from ports or base.

I have been using this patch for a couple weeks with LibreSSL 2.5.1 now and the
improvement is remarkable; almost all the SSL validation errors I'd been seeing
have disappeared as have the "couldn't resolve symbol" messages that had been
littering my logs.

-- 
You are receiving this mail because:
You are the assignee for the bug.