This change deprecates the old LayersIntroducingVulnerability for a new
one that orders output and contains an Index. This index is not
guaranteed to be consistent across multiple notifications, despite the
current Postgres implementation using the primary key of Layer table.
`searchNotificationAvailable` never effectively use any indexes because:
- `notified_at < $1`, where $1 is a recent timestamp, returns the
majority of the table and therefore it is cheaper for PostgreSQL
to use a sequential scan on the table.
- there is no index for `deleted_at IS NULL`.
However, when Clair has been running for long enough, the grand majority
of rows (99%+) are expected to have a non-NULL `deleted_at` field. This
commit adds a new index on this very field in order to fetch the
remaining 1% in the blink of an eye.
In other words, instead of realizing a full table scan for each
`searchNotificationAvailable` query, we'll use the small branch of a new
index, reducing the total cost from over 30k to a mere 150 on a Clair
database that has already managed more than 1 000 000 notifications.
If a Vulnerability that goes through the NVD metadata fetcher has an
empty or Unknown Severity, then use the CVSS score to set one. This
will help to get a more consistent database when a vulnerability source
does not provide this information.
We extracted oval parser from rhel and used that for opensuse and
SUSE Linux Enterpise
Signed-off-by: Thomas Boerger <tboerger@suse.de>
Signed-off-by: Jordi Massaguer Pla <jmassaguerpla@suse.de>
Until https://github.com/coreos/clair/pull/193 is merged, having
vulnerabilities that are tagged both rhel and centos would duplicate in
the database or use a change that requires a migration.
But presently due to the fetcher logic, the rhel provided
vulnerabilities are labelled for centos, and then the namespace does not
match and therefore not tested against.
So until such a day that a vulnerability could have both rhel and centos
label, then hack this in. It'll accomplish the same during this interim.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Due to the detector registration and fact that their in a non-ordered
map, it is random whether the osrelease or redhatrelease detector would
hit. And likely resulted in alternately formatted namespace strings.
This change causes the osrelease to not detect when data has
centos-release or redhat-release, which is not _great_ because if the
redhatrelease detector is not compiled in, then that would not be a
fallback that the osrelease detector could rely on. :-\
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
