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.
good to know that the update was supplied - thanks for sharing!
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?
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.
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
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.
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.
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.
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.
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
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?
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).
