Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1394233

Summary: kdelibs: kssl FTBFS against openssl-1.1.x
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: kdelibsAssignee: Than Ngo <than>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jgrulich, jreznik, kevin, me, ovasik, rdieter, smparrish, than
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-20 16:33:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1383740    

Description Rex Dieter 2016-11-11 12:53:44 UTC
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:

Comment 1 Kevin Kofler 2016-11-11 13:13:48 UTC
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:
They don't have any fixes yet. So either we fix it or we wait.

Comment 2 Rex Dieter 2017-02-20 16:33:03 UTC
Using compat-openssl10-devel moving forward, I doubt this (or Qt4) will ever fully support the newer api

Comment 3 Kevin Kofler 2017-02-20 18:29:56 UTC
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:

Comment 4 Rex Dieter 2017-02-20 18:31:08 UTC
Does that imply they've fixed Qt too?

Comment 5 Kevin Kofler 2017-02-20 18:44:10 UTC
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.

Comment 6 Kevin Kofler 2017-02-20 18:45:30 UTC
(Note that the symbol versioning also probably only helps if we keep using -openssl-linked. dlsym does not support symbol versioning.)

Comment 7 Kevin Kofler 2017-02-20 18:52:34 UTC
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.