https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216781
--- Comment #1 from [email protected] --- 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.
