On Sun, Oct 10, 2021, 10:38 Timo Aaltonen <tjaal...@debian.org> wrote:
> On 10.10.2021 18.41, Spencer Olson wrote: > > Did some more investigation. I downloaded the packages that are being > > used on centos stream 8. First I tried my test code with their version > > of libssl3.so preloaded: it failed in the same way as all the others > > failed--not surprisingly since its version is much later than the 3.39 > > version where this changed. > > > > Then, I downloaded and took a look at "dogtag-submit" from the CentOS > > Stream 8 (RedHat) certmonger package. As far as I can tell, their > > version of "dogtag-submit" is *not* linked against libcurl-nss.so at all > > like the version on debian sid. Instead, all their certmonger helper > > programs are linked against the OpenSSL version (libcurl.so.4). > > > > So, I think that we should just link these against the openssl version, > > as the RedHat packages do and get things to work again. > > Hmm, thanks.. indeed certmonger is still built against libcurl4-nss-dev, > I've changed it to openssl now and see how it goes against gitlab CI.. > Maybe the CI will finish before I can get back to my testing. > > This raises two other issues: > > - is there truly a bug in the ssl portion of the nss library? If so, > > this should probably be brought to the attention. > > - perhaps the libcurl package ought to be reconfigured such that one can > > install the dev packages simultaneously. Right now, libcurl-nss also > > makes a symlink "libcurl.so" that makes it conflict with the > > libcurl-openssl package to which the "libcurl.so.x.x" lib belongs to. I > > think that the libcurl-gnutls package might do the same thing. > > > > My next step will be do rebuild freeipa and certmonger with the > > libcurl-openssl-dev package in place instead of the libcurl-nss-dev and > > then try reinstalling. > > No need to rebuild freeipa. > Yep, you are right. I thought I had seen that freeipa had installed some executables with linkage to libcurl-nss in /use/lib/certmonger, but i was mistaken.