I’m having a major frustration with curl.
When building curl, if libssl.so.10 is present the curl binary WILL link against it.
If curl is configured with an ssl option – the library WILL link against it.
If you change the curl configuration options to use a different TLS
library (e.g. nss like CentOS does) the curl binary and library will still link against the OpenSSL library.
There’s definitely something funny about curl’s ./configure –
If you disable features but they are still pulled in by mock as dependencies for the build environment, the curl library will respect your configure options and won’t link against those features (except it will for libssl.so.10 if ANY tls option is chosen) but the binary will link against the libraries if it is there. EVEN IF THE DEVEL PACKAGE
WITH HEADER FILES IS NOT PRESENT.
There is something very broken about how curl builds. If I was a skilled blackhat, I might look for ways that causes it to be exploitable, because the building of curl doesn’t do what the user expects.
I tried building curl creating a mock build environment where openssl is forbidden. There’s a bug in mock.
In both base and updates I have
I had to rebuild many packages against LibreSSL to get that to work.
That btw is what I’m trying to do with curl – build it against LibreSSL
and it does, but also links against libssl.so.10 and there is the problem – it’s not safe to have a library (or binary) that links against both OpenSSL and LibreSSL.
With the presence of those excludes – mock does prevent the installation of openssl packages *in some cases* but it allows it others.
rpm depends upon curl and curl from the CentOS packages depends upon libssl.so.10 and mock pulls in rpm and thus pulls in curl and thus pulls in openssl-libs and so if building curl in mock – it will link against openssl.
I went through everything in the mock buildroot with ldd and curl is the ONLY package installed that has anything linked against openssl.
I tried building an intermediate curl for mock to pull in without any TLS capabilities – it works for the library but the curl binary still links against openssl.
I tried building an intermediary RPM package that doesn’t require curl –
but something else in the build system is pulling in curl resulting in libssl.so.10 being installed.
I wish mock didn’t have this bug as if it actually respected the excludes on base and updates, it would tell me what packages are pulling in openssl-libs but unfortunately there are cases where the excludes are not respected.
This is really frustrating.
I tried looking through the curl buildsystem to see if I could patch that but it seems messy to me and I can’t find why the binary links against libraries you disable with configure and I can’t see why the library always links against openssl if any TLS is chosen.
It’s very frustrating.
No other package I’ve rebuilt against LibreSSL has this problem.
With curl its a big problem.
It definitely should not be linking against libraries it doesn’t even have the right headers for.