CentOS packages not properly recognised due to dist tag in package release

[waananen]

Hi

A few recent packages from RHEL including httpd, ntp, firefox are not properly recognised due to the format of the release field and different content of dist tag. The current build dist tags are:

RHEL7: dist .el7_4 CENTOS7: dist .el7.centos

while the httpd specfile has a release tag is:

Release: 67%{?dist}.6

This means that the logic of the vercmp in lib/managers/VulnerabilitiesManager.php fails see the CentOS packages as fixes for the CVEs. It is not really feasible to create CVE exceptions manually. I have looked into hacking lib/managers/VulnerabilitiesManager.php without much luck.

Any idea on how to solve this (without asking Red Hat to change the format of the release field)?

Best

Anders

[kouril]

Hi Anders,

I'm not sure I quite understand the problem, could you please post the whole version strings of the packages?

Daniel

[waananen]

Hi Daniel

On CentOS7: rpm -q --qf '%{version} %{release}\n' httpd 2.4.6 67.el7.centos.6

On RHEL7: rpm -q --qf '%{version} %{release}\n' httpd 2.4.6 67.el7_4.6

Anders

[kouril]

Hi Anders,

I spent some time looking at the issue but am afraid there's no ideal solution as long as CentOS starts issuing information of vulnerabilities. We haven't been hit by the problem so far since none of the vulnerabilities we've chased so far were in customized CentOS packages. At the moment I see two possible solutions. You can either utilize the mechanism of local OVALs, which basically allows you to record your own information about vulnerabilities, based on the CentOS versions (should be more suitable then exceptions). The other option is to use the CentOS VDS module I drafted, which populates the DB with records that should match the CentOS versions (derived from RH OVAL, based on a simple syntax pattern). I haven't tested it on a real deployment, though. If you want to give it a try, please check the current master (commit 276b50d) and enable the module in your server.

Daniel

[kouril]

For the sake of completeness, the same issue may affect Scientific Linux (or other derivates), which would require additional increasing of imitated vulnerabilities.

Another way to address the situation on the Pakiti side would be to adapt the version comparing method to detect the dist part of release (el7_* etc.) and handle it appropriately. However, that would add a hack into the standard comparing algorithm and (more importantly) impact the part of code that is heavily used (with likely performance penalty).

Ideally of course, the distributions should publish their own OVALs, etc.