openssl-1.1.x API changed (at least) a bit breaking kssl , some notable build.log errors: /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp: In member function 'void KSSLCertChain::setChain(const QList<KSSLCertificate*>&)': /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp:48:26: error: 'class KOpenSSLProxy' has no member named 'sk_new'; did you mean 'BIO_new'? #define sk_new d->kossl->sk_new ^ /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp:154:22: note: in expansion of macro 'sk_new' _chain = (void *)sk_new(NULL); ^~~~~~ /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp: In member function 'void KSSLCertChain::setChain(void*)': /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp:48:26: error: 'class KOpenSSLProxy' has no member named 'sk_new'; did you mean 'BIO_new'? #define sk_new d->kossl->sk_new ^ /builddir/build/BUILD/kdelibs-4.14.25/kio/kssl/ksslcertchain.cpp:179:18: note: in expansion of macro 'sk_new' _chain = (void *)sk_new(NULL); See also: https://koji.fedoraproject.org/koji/taskinfo?taskID=16387342
I know. Both kdelibs 4 and kdelibs3 need fixing. No patch available yet. It looks like Fedora is as usual the only distro crazy enough to already ship OpenSSL 1.1. I have checked: https://quickgit.kde.org/?p=kdelibs.git&a=shortlog http://mirror.git.trinitydesktop.org/cgit/tdelibs/log/ https://github.com/patch-exchange/openssl-1.1-transition https://build.opensuse.org/package/show/KDE:Frameworks5/kdelibs4 https://build.opensuse.org/package/show/KDE:KDE3/kdelibs3 They don't have any fixes yet. So either we fix it or we wait.
Using compat-openssl10-devel moving forward, I doubt this (or Qt4) will ever fully support the newer api
Actually, Trinity ported their fork of the KDE 3 KSSL to OpenSSL 1.1, the patch can probably be backported to our kdelibs3 and then forward-ported to our kdelibs 4 and then forward-ported again to our kf5-kdelibs4support. I just haven't found the time to work on it yet, so if anybody else wants to have a try: http://mirror.git.trinitydesktop.org/cgit/tdelibs/commit/?id=e1861cb6811f7bac405ece204407ca46c000a453
Does that imply they've fixed Qt too?
As far as I can tell, no. The hope is that the symbol versioning used by OpenSSL is enough to prevent runtime symbol conflicts, but whether that is the case, I don't know.
(Note that the symbol versioning also probably only helps if we keep using -openssl-linked. dlsym does not support symbol versioning.)
I also think that if we find the time, we should really give the OpenSSL 1.1 patch for Qt another try. In principle, with -openssl-linked, if we get it to compile, it should also run. The issues with runtime failures we had were because we were trying to use the dlopening, which of course fails when the prototypes in Qt do not match the ones in OpenSSL. -openssl-linked does not have this issue.