FAQs
Frequently Asked Questions
Last updated
Was this helpful?
Frequently Asked Questions
Last updated
Was this helpful?
The difference between OVAL v1 and v2 is strictly structural. In OVAL v2 content is separated into streams instead of flat files or "everything" zip files.
Red Hat is no longer actively improving OVAL v1 and at some point OVAL v1 feeds will completely go away.
You will notice that OVAL v1 content is still being generated, but not for much longer. Our goal was content parity between OVAL v2 and OVAL v1; which we've achieved and thus why we'll be deprecating OVAL v1 soon.
Currently there is no OVAL v3 on the roadmap.
Red Hat OVAL roadmap includes adding additional content to the OVAL v2 feed; namely container first (non-rpm) content. No ETA can be provided at this time.
As per Red Hat Product Security, Red Hat is no longer producing OVAL data for kpatch errata.
To test vulnerability of a given flaw we'd have to compare a combination of installed kernels, installed kpatches, running kernel version, and boot config. It is not meaningful to write tests based on the kpatch rpm version alone. DevOps team feels that OVAL tests written based on the kpatch rpm version alone can lead to false positives. What is seen in the OVAL v1 feed, for package “kpatch-patch” is likely just leftover data.
Red Hat is considering kpatch in OVAL v2 files referencing the kernel; but it is not on the roadmap at this time.
Examples:
Very rarely you will see a Red Hat Security Advisory (RHSA) without a CVE.
this is an exception and
this is very very rare, ie. an outlier.
Currently there is no plan to provide OVAL 2 definitions via JSON. We might add them to the roadmap in the future as we work through current priorities.
rhel-7-including-unpatched.oval.xml.bz2
rhel-7-extras-including-unpatched.oval.xml.bz2 ; what is the difference between the two?
The RHEL Extras channel is intended to give customers access to select, rapidly evolving technologies. These technologies may be updated more frequently than they would otherwise be in a Red Hat Enterprise Linux minor release. RHEL extras is essentially a separate CPE than RHEL.
No, Red Hat does not plan to add CVSSv3 base score to backdated RHSAs.
(a) Why is there a difference between the two?
(b) When the state isn't listed, does that mean all versions are affected?
(a) In a "fixed" or "patched" OVAL definition there is a fix released for the erratum. So the tests are essentially checking if "$version < whatever the erratum released" is installed. The state_ref is where the "< $version" test is specified. In the "unfixed" or "unpatched" OVAL definitions there is no version to work with, so it's a simple "X is installed" test. Hence there is no state_ref. (b) It means the same thing as us putting an "affected" entry on a CVE: it indicates that Red Hat evaluated the latest version for that product and found it vulnerable. It means Red Hat doesn’t have a fix yet. It doesn't necessarily mean that old versions are also affected. Red Hat doesn’t evaluate all the old versions.
and were regarding the “Spectre and Meltdown vulnerabilities”. The fix was for multiple architectures and spread across multiple errata, so for tracking purposes the CVE field was left blank (to prevent a 1:1 mapping). The guidance is if the CVE field is blank in the advisory then
More information on RHEL “Extras” can be found .
Yes, these mappings can be found . These mappings are maintained by Red Hat Product Security.
No, the title doesn't always represent a repository as there is not necessarily 1:1 relationship between platform and repository. This is why we maintain .