On Wed, Mar 18 2020, Rafael Sadowski <raf...@sizeofvoid.org> wrote: > On Tue Mar 17, 2020 at 06:09:20PM +0100, Theo Buehler wrote: >> X509_getm_notBefore(), aka the gift that keeps on giving... >> >> jca pointed out to me that kde/libs failed to build on ld.bfd >> architectures due to a linking error in libkio [1]: >> >> /usr/obj/ports/kdelibs-4.14.10/build-sparc64/lib/libkio.so.50.3: undefined >> reference to `X509_getm_notBefore' >> /usr/obj/ports/kdelibs-4.14.10/build-sparc64/lib/libkio.so.50.3: undefined >> reference to `X509_getm_notAfter' >> >> This started happening after I fixed a qt4 SSL-related runtime failure >> that rsadowski@ showed me during p2k19. >> >> Before that fix, it linked, but only by accident. This was defintely >> broken on all architectures since August 2018. >> >> This is what happened (the notAfter case is the same): >> >> X509_get_notBefore(x) used to be a macro that reached inside the X509 x. >> In OpenSSL, this macro was replaced with a function, >> X509_getm_notBefore(), and openssl/x509.h now contains >> >> #define X509_get_notBefore X509_getm_notBefore >> >> so when an linking a program that uses X509_get_notBefore() this means >> ld.bfd will look up X509_getm_notBefore(). >> >> When trying to adapt the Qt4 openssl symbols sausage factory to this, I >> accidentally exposed a bogus symbol X509_getm_notBefore() in QtNetwork, >> which was enough to make ld.bfd happy. The Qt symbol lookup madness got >> rightfully confused by this, and this led to the segfault rsadowski >> showed me. The Qt4 side was fixed last November (although there should >> have been a major bump for QtNetwork and some other Qt libraries). >> >> The diff below fixes libkio by adding a symbol lookup similar to other >> libcrypto symbols and using it in ksslcertificate.cpp in place of the >> macro. Note that this is internal only, so no library bump required. >> >> check_sym shows the expected removal of the two external references to >> X509_getm_notBefore and X509_getm_notAfter for libkio. >> >> I have build tested this on amd64 and sparc64. > > With some meaningful comments in the new patches, ok with me but please > wait for jca@' feedback. Thanks tb
Wait, I'm no expert in how to run an OpenSSL sausage factory! That being said, thank you Theo for your thorough analysis. Your fixes seem to fit properly in the existing code. ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
