Fixed issue where rhel >8 packages would not have correct openssl dependency version

[craigcomstock]

We build against systems with the latest available dependencies such as OpenSSL.
libcurl builds against this OpenSSL version which can have API changes that will break functionality if used on a non-updated system.

Ticket: ENT-12587
Changelog: title

[vpodzime]

Looks good to me otherwise. One thing that worries me, though, is that I knew the fixed 3.0.0/3.0.1 would stop working at some point, but I expected our tests to catch this. How come that is not the case?

[vpodzime]

Not sure if it's worth complicating the commit message, but this change means we require some API level, not a specific version of openssl. The commit message says hard dependency on the exact version and that's not the case. Any version that provides the required API level is fine (i.e. basically also any newer version). I'd reword the commit message so that in case someone goes searching for this commit, they don't get the impression that if there's a CVE in OpenSSL, they will be stuck on the some version because of CFEngine.

[craigcomstock]

Not sure if it's worth complicating the commit message, but this change means we require some API level, not a specific version of openssl. The commit message says hard dependency on the exact version and that's not the case. Any version that provides the required API level is fine (i.e. basically also any newer version). I'd reword the commit message so that in case someone goes searching for this commit, they don't get the impression that if there's a CVE in OpenSSL, they will be stuck on the some version because of CFEngine.

Agreed. They will be required at a minimum VERSION of OpenSSL nothing to do with an API requirement except that yes, the version we build with is the API version we build against.

Happy to change the commit message to reflect this.

[craigcomstock]

@cf-bottom jenkins with exotics no tests (I will test manually installing on non-updated rhel-8/9)

[cf-bottom]

Alright, I triggered a build:

(with exotics) [NO TESTS]

Jenkins: https://ci.cfengine.com/job/pr-pipeline/12092/

Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-12092/

[craigcomstock]

had a typo, retry: @cf-bottom jenkins with exotics no tests

[cf-bottom]

Sure, I triggered a build:

(with exotics) [NO TESTS]

Jenkins: https://ci.cfengine.com/job/pr-pipeline/12093/

Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-12093/

[vpodzime]

They will be required at a minimum VERSION of OpenSSL nothing to do with an API requirement except that yes, the version we build with is the API version we build against.

TL;DR

It has to do with API level requirements, really.

Just to elaborate on what I meant

The provides returned by rpm -q --provides are based on symbol names/versions in the libraries' ELF files. So even if we build with openssl-3.5.0 the highest symbol name/version in the libssl and libcrypto libraries will determine the provides and thus our requires. If we wanted to go with a finer-grained approach, we would check the libraries and binaries we build and determine the highest symbol/name version based on what we actually link with. Then, even when building with openssl-3.5.0 we could easily require 3.2.0 or higher or something similar as long as we and our dependencies didn't use any newer symbols.

Thanks for adjusting the commit message!

[craigcomstock]

They will be required at a minimum VERSION of OpenSSL nothing to do with an API requirement except that yes, the version we build with is the API version we build against.

TL;DR

It has to do with API level requirements, really.

Just to elaborate on what I meant

The provides returned by rpm -q --provides are based on symbol names/versions in the libraries' ELF files. So even if we build with openssl-3.5.0 the highest symbol name/version in the libssl and libcrypto libraries will determine the provides and thus our requires. If we wanted to go with a finer-grained approach, we would check the libraries and binaries we build and determine the highest symbol/name version based on what we actually link with. Then, even when building with openssl-3.5.0 we could easily require 3.2.0 or higher or something similar as long as we and our dependencies didn't use any newer symbols.

Thanks for adjusting the commit message!

Right. Reviewing the output of -q --provides openssl-libs and checking man rpm which says

       --provides
              List capabilities this package provides.

I see that doesn't provide ANY inkling of what information it is giving so didn't indicate to me any of what you are mentioning. Bad docs for sure I'd say.

So. As I understand it from you this -q --provides openssl-libs examines symbols in the libraries and returns essentially the Version Definitions from the ELF/shared-object (visible with objdump -p /usr/lib64/libcrypto.so for example). I don't quite understand what these are but will trust that they are linked dependencies between libcrypto.so and libssl.so.

Correct, so it is an API version expressed in a version which we then use in Requires.

I will amend the comment again to be more clear.

[craigcomstock]

Thanks @vpodzime and @larsewi . I will test the packages when they are ready and if OK I will merge and fixup the cherry picks with these commits.

[vpodzime]

As I understand it from you this -q --provides openssl-libs examines symbols in the libraries and returns

Not exactly. When you do -q --provides, it only gives you whatever is stored in the RPM DB (or an RPM package, if you point it to a file). The symbol examination happens when an RPM is built and populates the metadata. Similarly, when an RPM is built, dependencies on dynamic libraries are determined based on the ELF files in the package and their NEEDED info. Which is what we disable because we ship our dependencies ourselves.

[craigcomstock]

As I understand it from you this -q --provides openssl-libs examines symbols in the libraries and returns

Not exactly. When you do -q --provides, it only gives you whatever is stored in the RPM DB (or an RPM package, if you point it to a file). The symbol examination happens when an RPM is built and populates the metadata. Similarly, when an RPM is built, dependencies on dynamic libraries are determined based on the ELF files in the package and their NEEDED info. Which is what we disable because we ship our dependencies ourselves.

Nice. Thanks for the clarification.

[craigcomstock]

Looks good to me:

[vagrant@rhel9 ~]$ sudo yum install cfengine-nova-hub-3.26.0a.20fcd8b8c-1692.el9.x86_64.rpm
Extra Packages for Enterprise Linux 9 - x86_64                                                         13 MB/s |  23 MB     00:01    
Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64                                  794  B/s | 2.5 kB     00:03    
Last metadata expiration check: 0:00:01 ago on Tue 06 May 2025 12:43:40 PM UTC.
Error: 
 Problem: conflicting requests
  - nothing provides selinux-policy >= 38.1.45 needed by cfengine-nova-hub-3.26.0a.20fcd8b8c-1692.el9.x86_64 from @commandline
  - nothing provides libssl.so.3(OPENSSL_3.2.0)(64bit) needed by cfengine-nova-hub-3.26.0a.20fcd8b8c-1692.el9.x86_64 from @commandline
  - nothing provides libcrypto.so.3(OPENSSL_3.2.0)(64bit) needed by cfengine-nova-hub-3.26.0a.20fcd8b8c-1692.el9.x86_64 from @commandline
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

and after upgrading packages the package installs as normal.

[vpodzime]

and after upgrading packages the package installs as normal.

I don't understand why this is necessary. I believe yum install ... should pull in the upgrade into the transaction. Anyway, it works well from our side, the behavior above just looks like a bug in yum (dnf, really) to me.