Some errata missing in comparison with RHEL and AlmaLinux

Hi Rocky team,
first of all - thanks a lot for your great job! I’ve been a CentOS user for a very long time and I highly appreciate your work on supplying an alternative.

Currently I’m preparing a talk for the FrOSCon conference (Lecture: CentOS ist tot, lang lebe CentOS | Saturday | Schedule FrOSCon 2021 Cloud-Edition) about CentOS and alternatives. As there is also AlmaLinux beside Rocky Linux and people often ask about the differences I decided to compare these two distros. I saw that Rocky Linux offers errata information - I compared those information with the official Red Hat Security Advisories (Red Hat Customer Portal - Access to 24x7 support and knowledge) and saw that there are several patches that are not available on Rocky Linux - but on AlmaLinux:

  • RHSA-2021:2566 (fwupd)
  • RHSA-2021:2743 (Firefox)
  • RHSA-2021:2988 (varnish)
  • RHSA-2021:3020 (Ruby 2.7)
  • RHSA-2021:3027 (microcode_ctl)
  • RHSA-2021:3066 (edk2, QEMU UEFI)
  • RHSA-2021:3075 (libuv, async I/O)
  • RHSA-2021:3076 (go-toolset)
  • RHSA-2021:3079 (389-ds)

Is there a reason for this? What did I miss?

Best wishes and thanks a lot in advance,
Christian.

Lets take a peek with:

  • Red Hat issued errata (and package fwupd-1.5.9-1.el8_4) 2021-06-29
  • CL8 repo has fwupd-1.5.9-1.el8_4 with date 2021-06-29
  • AL8 repo has fwupd-1.5.9-1.el8_4.alma with date 2021-07-06
  • RL8 repo has fwupd-1.5.9-1.el8_4 with date 2021-07-20

All three clones have the package. Build dates differ. You do know that CentOS too has had delays on build and release for various reasons.

Counter-example, I don’t see perl-5.26.3-419.el8_4.1 in AL8 repo. RHEL issued it 2021-08-10. Both CL8 and RL8 have it.

1 Like

Hi jlehtone,

good to know that the update was supplied - thanks for sharing! :slight_smile:

I was just wondering why there was no errata supplied. Looks to me like it was shipped as conventional package upgrade instead of security advisory - am I right? I understand that the packages are replicated (and debranded) in an automated way - does this also apply to errata as well?

Best wishes,
Christian.

Hi Christian,

while I am not affiliated with the Rocky Linux project, I have a theory:

One way to find the Red Hat “parent” errata is to check the change log (in the git commit) for BZ (Bugzilla) references. These have a status “errata closed” with a link to the published errata.

Sometimes these BZ tickets are private, so this information is unavailable.

Just my €0.02.

Kind regards,
Steve

1 Like

Yep! The errata pipeline is exactly the same. More information on the exact pipeline is being documented for the public, as well as the associated code.

The long story short is that @mustafa has composed a beautiful piece of software which is able to synchronize errata information from RH which enables things like dnf update --security and other commands to work.

The actual build process is the same for any package update–security, bug, or otherwise. Once we receive notification (generally via automation and/or the message bus) that a package is updated, it is debranded if necessary, and rebuilt. There are times where the releng team needs to work to fix some package build issues, and there are some growing pains especially around dotnet and some other packages where we have to custom-debrand each time until we can become officially supported in the upstream projects… but those are on their way!

We aim to have most updates turned around and promoted to our Tier 0 mirror for synchronization around the world within 24-48 hours of release–though this is not “technically” an SLA, as it’s more of a best-effort :wink:

Edit to add: You can also check out https://errata.rockylinux.org ! Any features/etc you might want please feel free to open a bug or comment here if there’s not a place for it. We’ve got RSS feeds and (tangentially) email announce lists in the pipeline.

3 Likes

Hey!

You’re right about some advisories missing. Currently our automated errata software relies on all components affected by the CVE to be fixed before issuing an advisory. This was obviously a mistake on my part and change is underway. The ruby2.7 advisory is in our system, but the system refuses to publish it because some of the CVEs affects 2.6 and 2.5 as well and those haven’t been addressed yet.

Even though errata hasn’t been published, the packages are updated.
Sorry for any inconvenience caused by this and we’re working as fast as possible to do a structure revamp to fix this.

2 Likes

Hey,
thanks for explaining the way how advisories are processed. Helps a lot.

Also thanks a lot for your efforts!

Best wishes,
Christian.

Hi everyone!

Not sure that I should start new thread with my question - so I’ll try to ask here.
I also made some comparison analysis between RH errata and Rocky Linux.

There are two advisories:

both of them are about nginx - 2259 is for nginx:1.18 and 2290 is for nginx:1.16

Rocky Linux errata has similar advisories (sorry, can’t attach more that 2 links):

  • RLSA-2021:2259
  • RLSA-2021:2290

But the problem is in affected packages: while in RH bulletins package versions are separated (1.18 versions for 2259 bulletin and 1.16 for 2290 respectively), both RLSAs contains the same amount of packages with mixed versions - both 1.18 and 1.16.

Is it a bug or there is some logic in it?

Also let me ask another question:
is it possible to get errata with epochs in affected packages versions? As I can see now - there is no epochs at all.

Many thanks to the team for great job!

Kind regards,
Andrey

Found same case for:

RLSA-2021:3623 and RLSA-2021:3666 has same list of mixed packages of 12 and 14 nodejs versions.

It’s a consequence of an implementation detail that we’re reworking now. Both advisories having identical set of packages is because of a mistake in the internal structuring regarding how we pull affected RPMs (by CVE vs by CVE&affected product).

It shouldn’t cause any issues for now, but we’re definitely working on restructuring this and will re-issue advisories affected. Adding epochs should definitely be possible, I’ll note it.

The restructured version of the automated errata platform will definitely be more polished and will address these details :slight_smile:

Thanks a lot!

Looking forward to further updates :slightly_smiling_face:

Best,
Andrey