Remediating openssl 3.0.7 vulnerability

Rocky Linux General
1

Rocky 9 default image ing Google Cloud from yesterday has 3.0.7-25 and the source code for 3.0.13 was released on January 30th, 2024.

I compiled it from source and ssh works but dnf gives errors that the underlying openssl error

# dnf install joe
Traceback (most recent call last):
  File "/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.9/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.9/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python3.9/site-packages/libdnf/__init__.py", line 12, in <module>
    from . import conf
  File "/usr/lib64/python3.9/site-packages/libdnf/conf.py", line 13, in <module>
    from . import _conf
ImportError: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

I have seen a lot of documentation on how to compile openssl but not a lot about how to deal with these incompatibilities.

Can anyone recommend some documentation that deals with what I am encountering?
Is what I am trying to do a bad idea?
How long does it usually take from the day source code is released until an rpm is pushed to the repo?

Thank you.

2

Then you don’t have “Rocky Linux” any more. If your system is broken – as it probably is – you can keep the pieces. One does not simply replace core system components in Enterprise Linux.

The “3.0.7-25” that is in Rocky is not the 3.0.7 that upstream openssl has had. See https://access.redhat.com/solutions/57665

3

Luckily it was a vm I deployed to test this. The experience helped me learn a lot about how these things are remediated and the nature of openssl and other core packages.

4

A bit longer version:

Red Hat has their own branch of openssl for RHEL 9 that they have based on (forked from) upstream 3.0.7. They primarily backport changes to their branch.

Red Hat can introduce new features to RHEL on point updates, which are released every six months. The features come either by backport or rebase. Red Hat tries to avoid changes that break compatibility with other components. Hence rebases are less common. For example, kernel has never been rebased, AFAIK. Red Hat has at least once rebased openssl in one major version of RHEL (6 or 7?). In that case the rebase must have been “cheaper” than backports, but it did break compatibility and forced changes to many packages and installed systems.

If “nothing” depends on package, then it could be rebased safely. User applications, like Firefox, belong to that category. (Although even that can force changes – in user.)

Therefore, the answer to “how long?” could be “never”, “next major version”, or “next point update”.

The package manager knows what files come from a package, so it knows what to remove on uninstall of package (and update does uninstall old version). It also knows if new package would overwrite file from some other, installed package. A source install does not know about other files, nor notify package manager.

When I build and install something from source, I do it as regular user and install to location that is not any of the system directories. Then I usually create “module file” for environment modules tool, that the tool can use to modify environment of current shell session to add location of application to PATH, etc.

If you think that “ok, lets make RPM from sources so package manager can manage”, yes that is possible. However, it requires all the same compatibility considerations as Red Hat has to go through. Furthermore, you become the maintainer for that package on your systems and have to update it (rebase or backport, build, and install) whenever necessary.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.