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 bugzilla.redhat.com.
Bug 1394233 - kdelibs: kssl FTBFS against openssl-1.1.x
Summary: kdelibs: kssl FTBFS against openssl-1.1.x
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kdelibs
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1383740
TreeView+ depends on / blocked
 
Reported: 2016-11-11 12:53 UTC by Rex Dieter
Modified: 2017-02-20 18:52 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-20 16:33:03 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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:
https://koji.fedoraproject.org/koji/taskinfo?taskID=16387342
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:
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.
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:
http://mirror.git.trinitydesktop.org/cgit/tdelibs/commit/?id=e1861cb6811f7bac405ece204407ca46c000a453
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.
Note You need to log in before you can comment on or make changes to this bug.