Patching EOL CentOS
Patching EOL CentOS is not as straightforward as it seems. In this video, Rich Alloway and Javier Perez from OpenLogic by Perforce explain the process of backporting and testing patches for EOL CentOS.
This clip is from the OpenLogic webinar, “CentOS 7 End of Life: Why You Need to Start Planning for EOL Today” that aired on November 16, 2023. To watch the full webinar, click here: https://ter.li/lpuh5n
Looking for CentOS Long-Term Support? See our solution: https://ter.li/amyyb3
- -
About OpenLogic by Perforce:
OpenLogic offers end-to-end enterprise support for organizations using open source software in their infrastructure. With support for over 400 open source packages, guaranteed SLAs, and direct access to highly experienced Enterprise Architects, OpenLogic customers benefit from 24x7 ticket-based technical support, professional services, and training.
Follow OpenLogic on LinkedIn, Twitter, and don’t forget to subscribe to our YouTube channel for more videos on all things open source!
- -
Transcript (lightly edited for clarity):
Rich: The first thing whenever we're faced with a CVE in one of the LTS products that we support is to research. We need to find out more about the CVE.
Is it repeatable, what is the attack vector? Is it only something that could be attacked locally? Is it something network adjacent or completely, remotely exploitable, over the network?
What is the severity of the CVE? So if it's CVSS score of seven versus ten, you know, ten is obviously gonna get a little more attention than just a seven.
And then we look at available patches from the upstream.
So most of the distributions that are out there, maybe all of them, are essentially a collection of packages from somebody else. So there's individual package maintainers who maintain versions of usually multiple versions of each package.
There's usually at least one as long as the package is still current, but they might also support other versions. So, like, for OpenSSL 3, you can still find patches or the source code for OpenSSL version 2.
So, typically, one of these end of life distributions that we're looking to backport a patch to is not going to be one of the supported versions. Typically with the 10-year life cycle of a RHEL derivative, the actual version doesn't get rebased very often. So the version that is still distributed with CentOS 7 today is, for the most part, the same version that was shipped when CentOS 7.0 came out. Just with backported patches by Red Hat. And so then we kinda step in after end of life, and we do some backporting of patches.
Almost no patches are just a lift from the package maintainer or from another distribution and just apply it. You actually have to know what the patch is doing and be able to backport the changes
Javier: That's a very important point. I want to double down on that just to make sure that people understand this big piece. What Rich just mentioned, is the fact that the Linux distribution, that the central distribution has an older version might make you think, well, why don't you just send us the latest OpenSSL?
Well, no, because that's gonna create issues.
Rich: That can have a cascading effect because, with something like Open SSL, libraries are installed on the system and other applications rely on those libraries. With OpenSSL 2 and OpenSSL 3, that's a major version difference between OpenSSL library versions. And just because something works for OpenSSL 2 doesn't mean it's gonna work with an OpenSSL 3 library. Even if the package is rebuilt.
Javier: Yeah. So very important in those cases to, as Rich mentioned, you take the patch, but then you have to backport to the version that it's on CentOS. In this case, it will be 6 or 8, and it's gonna happen for CentOS 7. And that's key. It's not as simple as just bringing the patch; in many cases, it has to be backported.
I interrupted you, Rich -- the end of the process here is you apply the patch and then you run testing before it's published. Right?
Rich: Sure. Yep. There's simple smoke testing, just make sure that the package installs and simple commands, or functions, associated with the package still work. During the actual build of the package, a lot of the packages will have a built-in test suite. And, outside of that, CentOS itself has a functionality test suite, which doesn't have coverage of every package, but if the package is covered in there, we'll run those tests on it as well. Make sure that everything is still good and running.