Plan for Security Vulnerabilities in Alma Linux 8.6

Dear Team,

Thanks for outstanding support to users on various issues through this Alma Linux community open forum. We sincerely appreciate your kind support and committed efforts on the same.

We started working on a new release in our product in July’2022 and planning to get it CCO by Jan’2023. At the start of development phase, we had AlmaLinux 8.6 as the latest, stable OS available, and we upgraded our underlying OS from Alma Linux 8.5 to 8.6.

Recently we ran security scan (tenable / nessus scan) in our new Alma Linux 8.6 and found below vulnerabilities, divided into 2 groups.

Group 1:

  1. Medium 166675 AlmaLinux 8 : kernel (ALSA-2022:7110)
  2. High 166508 AlmaLinux 8 : zlib (ALSA-2022:7106)
  3. High 166524 AlmaLinux 8 : device-mapper-multipath (ALSA-2022:7192)
  4. High 166462 AlmaLinux 8 : libksba (ALSA-2022:7089)
  5. Medium 166505 AlmaLinux 8 : samba (ALSA-2022:7111)
  6. Medium 166673 AlmaLinux 8 : sqlite (ALSA-2022:7108)
  7. Medium 166509 AlmaLinux 8 : gnutls (ALSA-2022:7105)

Group 2:

  1. High 167303 AlmaLinux 8 : freetype (ALSA-2022:7745)
  2. High 167442 AlmaLinux 8 : rsync (ALSA-2022:7793)
  3. High 167444 AlmaLinux 8 : httpd:2.4 (ALSA-2022:7647)
  4. High 167447 AlmaLinux 8 : kernel (ALSA-2022:7683)
  5. Medium 167438 AlmaLinux 8 : pcs (ALSA-2022:7447)
  6. High 167313 AlmaLinux 8 : qt5 (ALSA-2022:7482)
  7. High 167440 AlmaLinux 8 : gdisk (ALSA-2022:7700)
  8. Medium 167316 AlmaLinux 8 : unbound (ALSA-2022:7622)
  9. Medium 167306 AlmaLinux 8 : bind (ALSA-2022:7790)
  10. Medium 167292 AlmaLinux 8 : libxml2 (ALSA-2022:7715)
  11. Medium 167315 AlmaLinux 8 : yajl (ALSA-2022:7524)
  12. Medium 167445 AlmaLinux 8 : e2fsprogs (ALSA-2022:7720)
  13. Medium 167459 AlmaLinux 8 : libldb (ALSA-2022:7730)
  14. Medium 167307 AlmaLinux 8 : grafana (ALSA-2022:7519)
  15. Medium 167294 AlmaLinux 8 : grafana-pcp (ALSA-2022:7648)

Of these, we have fix for Group 1 vulnerabilities on Alma Linux 8.6.

However, we don’t have fix currently available for Group2 vulnerabilities in Alma Linux 8.6

As it is too late for us to to perform another OS upgrade (from 8.6 to 8.7) and given that stable alam 8.6 is released only around 2 weeks back, we need your kind support to release these vulnerability fixes in AlmaLinux 8.6 as well.

Kindly help/support as this a show stopper for our release.

Thanks,
Kiran

AlmaLinux 8.7 is the only supported version at this time. It is the only available “update” for the packages.

Hi Jukka V. Lehtonen,

Thanks for your response.

Does that mean Alma Linux 8.6 is End of Support / End of Life ?

Kindly consider our situation, where we don’t have Alma Linux 8.7 option during our development phase in Aug’2022 and now that 8.7 has been just released couple of weeks back, it is too tough for us to go for OS upgrade one month before our release. :frowning:

Thanks,
Kiran

Red Hat has RHEL 8. About every six months they release new “point release” that has some new features. Between point releases they release bug and vulnerability fixes for current point release.

Overall, the idea is that a RHEL major release can be used its entire lifetime (a decade) without significant changes to user services (that run with applications in RHEL). The feature updates ought to have minimal changes.

Red Hat does release sources for updates mentioned above. AlmaLinux rebuilds packages from those released sources.

See Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal
It does show that Red Hat does release bug and vulnerability fixes for RHEL 8.6 after RHEL 8.7 was released, but those are EUS (Extended Update Support) and Updates for SAP Solutions.

Red Hat does not release sources of EUS (US for SAP) packages.
The only way to access those is to purchase RHEL 8.6 EUS subscription.

There are no publicly available sources for “new” EL 8.6 content since release of EL 8.7
=> AlmaLinux (nor anyone else) cannot build packages for EL 8.6

If your product works only on RHEL 8.6, then only customers with RHEL 8.6 EUS subscription can use it now.

If your product is so tightly coupled to specific version of binaries that you cannot simply rebuild it against newer version of Enterprise Linux 8 libraries, then it is terribly fragile. Furthermore, product for 8.6 ought to have been released right after 8.6 was released and one should now have product for 8.7 ready for release.

you can of course just install security updates without moving to a whole new minor version release - you will essentially get the patches from 8.7 but it won’t become 8.7 (no new features or updated release file).

there’s a great albeit out-of-date article here: Is it possible to limit yum so that it lists or installs only security updates? - Red Hat Customer Portal

but essentially you can do things like:

dnf updateinfo list cves
dnf updateinfo list security
dnf updateinfo info security
dnf upgrade --security
dnf upgrade --advisory=ALSA-2022:7745

i know oracle has recently started recommending that you don’t just apply security patches as it can trigger dependency hell.

only supporting a specific point release is nonsense really as its not like you’re testing your software against every patch between 8.6 and 8.7, plus if you have a functional bug, the first thing you’ll have to do is install the latest patches to see if its already fixed that way.

1 Like

That debatable. Among the affected packages were kernel and qt. If you update those, then you will get both fixes and new features. We do know from all the 8.6/8.7 KDE-discussions that update of qt requires rebuild of every binary that depends on qt.

That is, if you wan’t only security fixes, then you should get sources of 8.6 packages, backport fixes to them, and rebuild (just like Red Hat does for EUS customers). However, then you have a system that nobody else in the world has.

Thanks for your support and responses. I shall discuss internally and get back on this