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,

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,

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,

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 ! 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.



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.


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

Also thanks a lot for your efforts!

Best wishes,

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,

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:


Hi @mustafa, thanks a lot for your efforts! I’m a maintainer of OSS vulnerability scanner Trivy and we’re trying to add support for Rocky Linux. We also need to identify modular streams such as nginx:1.16 and nginx:1.18 in advisories. Otherwise, we cannot determine which advisories should be used. Like the following case:

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

Could you add modular information to advisories in a machine-friendly format? Also, is there any update on the new errata system you’re working on?

The format that’s used tries to closely match what Red Hat provides in their own errata data. Could you go into detail on what you’d like to see and/or what problems you’re seeing with the current format?

Thanks for your reply! There are two issues as discussed above.

  1. Missing epoch
  2. RLSA regarding modular packages is mixing versions
    • i.e. RLSA-2021:2259 has versions for nginx:1.16 and nginx:1.18 both

I’d like to ask when the above two issues will be addressed.

What I requested is adding module information to RLSA. RHSA and ALSA have that. You can see the following examples.

I understand.

Note that almost all of our current efforts/free time has been put into the new build system, which is why we haven’t come back to this right away. Talking with Mustafa, we will try to prioritize time over the coming days and weekend as life and time permits. We can’t pin an ETA, because it has to work with both the new build system (coming soon) and the old build system (soon to be legacy) in parallel, to allow a smooth transition when we start building for Rocky 9. I can provide updates down the road when we get there. We’ll also likely announce the changes on the mail list (rocky-announce).

Thanks for the detail! We’ll describe the mail list and be looking forward to it.