fix(oracle): split version flavors

[DmitriyLewen]

Description

Oracle Linux uses normal, fips (e.g. 3.6.16-4.0.1.el8_fips) and ksplice (e.g. 2:2.28-151.0.1.ksplice2.el8) version flavors.
We need to separate these versions so that we only compare version with same flavors.
See #220 for more details.

PR info

We are currently unable to change the database schema, so this PR is workaround to keep multiple versions for single CVE.
We currently use FixedVersion for OS advisories.
But in this case PatchedVersions was used.

It adds options to save all flavors for single advisory.

To save backward compatibility - we only keep version with normal flavor in FixedVersion.

DB sizes:

before:

-rw-r--r--@ 1 dmitriy  staff    53M Oct  8 16:51 db.tar.gz
-rw-------@ 1 dmitriy  staff   507M Oct  8 16:50 trivy.db

after

-rw-r--r--@ 1 dmitriy  staff    52M Oct 14 17:48 db.tar.gz
-rw-------@ 1 dmitriy  staff   523M Oct 14 17:47 trivy.db

Related PRs

• fix(oracle-oval): Support multiple ELSAs per CVE #221
• fix(oracle): added multiple fixed versions for one CVE #222

[knqyf263]

Have you considered using ELSA-IDs for keys? It would require a modification on the Trivy side to also display CVE-IDs, but I don't think it would be that bad since the old Trivy only displays ELSA-IDs instead of CVE-IDs.

[knqyf263]

I suggested the same before 😄
#221 (comment)

[knqyf263]

Unless I'm overlooking something, backwards compatibility is diminished - because ELSA ID is used as the key and not the CVE ID, older clients utilizing the database will not be able to resolve the CVE and will report results like the following:

It's a fair point. I totally forgot about it.

[DmitriyLewen]

I'm not sure about that.

1. I can check, but I'm not sure we'll gain in DB size for this solution, because we'll need to create separate Entry for each CVE-ID (or use VendorIDs to merge CVEs with the same versions).
   We can try to use RedHat advisory with fixedVersion as array.
   If it is okay for you - i can try this and detect DB size
2. We'll need to add logic to remove 2 (or more) fixed versions (e.g. https://linux.oracle.com/cve/CVE-2014-7169.html contains 2 ELSA for bash (OL 5) => 2 fixed versions).
   So Trivy should solve this problem (which means Trivy will waste resources for such cases).

[knqyf263]

We can try to use RedHat advisory with fixedVersion as array.

Please let me think about it.

I'm now confused about FIPS. This adviosry seems relevant to FIPS according to the description, but the version doesn't contain _fips.

gnutls
[3.7.6-12]
- fips: mark PBKDF2 with short key and output sizes non-approved
- fips: only mark HMAC as approved in PBKDF2
- fips: mark gnutls_key_generate with short key sizes non-approved
- fips: fix checking on hash algorithm used in ECDSA
- fips: preserve operation context around FIPS selftests API

Do you have any ideas?

[DmitriyLewen]

hm... i couldn't to think explanation for that...
This is a changelog, so there may be typos...

ELSA-2022-9221 has fips version, but doesn't have fips prefies:

[3.6.16-4.0.1_fips]
- Allow RSA keygen with modulus sizes bigger than 3072 bits and validate the seed length
as defined in FIPS 186-4 section B.3.2 [Orabug: 33200526]
- Allow bigger known RSA modulus sizes when calling
rsa_generate_fips186_4_keypair directly [Orabug: 33200526]
- Change Epoch from 1 to 10

[knqyf263]

Another question. This vulnerability has no ELSA for FIPS. Does it mean FIPS gnutls is not affected?
It looks like the FIPS gnutls shares the code with the normal gnutls.
https://linux.oracle.com/errata/ELSA-2022-9221.html

[knqyf263]

This advisory is mixing up normal and fips flavors.

[DmitriyLewen]

This vulnerability has no ELSA for FIPS. Does it mean FIPS gnutls is not affected?
It looks like the FIPS gnutls shares the code with the normal gnutls.

Take a look - aquasecurity/trivy#1967 (comment)

Does it mean FIPS gnutls is not affected?

IIUC you are right (or there is no fix for FIPS gnutls)

[knqyf263]

We can use FixedVersion for normal flavor. Do we also need to store this version in PatchedVersions? It helps reduce the size.

[DmitriyLewen]

hm... after adding arches (#453) this logic will be confusing (because we will only keep normal version for x86_64 arch in FixedVersion)
But i will check your solution to understand how much space we can save.

[knqyf263]

Actually, I'm wondering how much using PatchedVersions helps from the size perspective after migrating to Advisories in #453.

[knqyf263]

I'll write an example. Just a moment.

[DmitriyLewen]

But I used PatchedVersions in #453 to avoid creating a new Entry for each flavor.

[knqyf263]

The PatchedVersions method needs a more complicated implementation as it needs to aggregate entries, but the data size will be bigger. There is no reason to go with that.

[DmitriyLewen]

Great research! So, we would go for FixedVersion, right?

Right!

The PatchedVersions method needs a more complicated implementation as it needs to aggregate entries, but the data size will be bigger. There is no reason to go with that.

agree with you!

[knqyf263]

OK, so are you going to update this PR?

[DmitriyLewen]

I think we don't need to add flavors and arches in one PR.
So I will update this PR, after merging this PR we will add arches.

[knqyf263]

Agree. We should add changes step by step.