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..
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.
--
t
