Revert "cve-check: change the default feed"

This reverts commit 8e11797a563066da97ffac639d3173281a8c1ca9.

Reverted the value from FKIE to NVD2, because the FKIE CVE database is 
not read properly by the cve-check script.

A lot of CVE entries are incomplete and incorrect. From what I can see, the majority of the CVEs are not correct with FKIE.

I can provide a simple example with CVE-2024-6119 (https://nvd.nist.gov/vuln/detail/CVE-2024-6119).

On the official database the severity for this CVE, with CVSS Version 3.x, is: 7.5 (HIGH) 

On a build with the FKIE database we have the following result: sqlite3 nvdfkie_1-1.db .dump | grep CVE-2024-6119

INSERT INTO NVD VALUES('CVE-2024-6119',replace('Issue summary: Applications performing certificate name checks 
(e.g., TLS\nclients checking server certificates) may attempt to read an invalid memory\naddress resulting in abnormal termination of t
he application process.\n\nImpact summary: Abnormal termination of an application can a cause a denial of\nservice.
\n\nApplications performing certificate name checks (e.g., TLS clients checking\nserver certificates) 
may attempt to read an invalid memory address when\ncomparing the expected name with an `otherName` subject alternative name of an\nX.509 certificate. 
This may result in an exception that terminates the\napplication program.\n\nNote that basic certificate chain validation (signatures, dates, ...) 
is not\naffected, the denial of service can occur only when the application also\nspecifies an expected DNS name, Email address or IP address.\n\n
TLS servers rarely solicit client certificates, and even when they do, they\ngenerally don''t perform a name check against a reference identifier 
(expected\nidentity), but rather extract the presented identity after checking the\ncertificate chain.  So TLS servers are generally not affected 
and the severity\nof the issue is Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.','\n',char(10))
,'0.0','0.0','0.0','2025-06-03T10:51:54.117','UNKNOWN',NULL);

You can see that the rode severity for CVSS Version 2.0, 3.0 and 4.0 are all set to '0.0', which is incorrect.

Now, with the NVD2 database: sqlite3 nvdcve_2-2.db .dump | grep CVE-2024-6119

INSERT INTO NVD VALUES('CVE-2024-6119',replace('Issue summary: Applications performing certificate name checks 
(e.g., TLS\nclients checking server certificates) may attempt to read an invalid memory\naddress resulting in abnormal 
termination of the application process.\n\nImpact summary: Abnormal termination of an application can a cause a denial of\nservice.
\n\nApplications performing certificate name checks (e.g., TLS clients checking\nserver certificates) 
may attempt to read an invalid memory address when\ncomparing the expected name with an `otherName` 
subject alternative name of an\nX.509 certificate. This may result in an exception that terminates 
the\napplication program.\n\nNote that basic certificate chain validation (signatures, dates, ...) is not\naffected, 
the denial of service can occur only when the application also\nspecifies an expected DNS name, Email address or IP address.
\n\nTLS servers rarely solicit client certificates, and even when they do, they\ngenerally don''t perform a name check against a reference identifier 
(expected\nidentity), but rather extract the presented identity after checking the\ncertificate chain.  
So TLS servers are generally not affected and the severity\nof the issue is Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected 
by this issue.','\n',char(10))
,'0.0','7.5','0.0','2025-06-03T10:51:54.117','NETWORK','CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H');

This is the correct severity for CVE-2024-6119.

The base issue does NOT come from the FKIE databse : https://github.com/fkie-cad/nvd-json-data-feeds/blob/main/CVE-2024/CVE-2024-61xx/CVE-2024-6119.json

We can see for this CVE a "baseScore": 7.5.

It seems like poky is not reading the FKIE database correctly, so we revert the change to NVD2 with a working and complete database.

Note: I only gave the example of CVE-2024-6119 with CVSS example, but as you can see other fields are not correct either with "UNKNOWN" status.
---
 meta/classes/cve-check.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Maybe it would be better to fix FKIE fetcher instead of giving-up on it?
See https://lists.yoctoproject.org/g/poky/message/13702

Peter

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of vboudevin via
> lists.openembedded.org
> Sent: Thursday, August 7, 2025 20:18
> To: openembedded-core@lists.openembedded.org
> Cc: vboudevin <valentin.boudevin@gmail.com>
> Subject: [OE-core] [PATCH] Revert "cve-check: change the default feed"
> 
> This reverts commit 8e11797a563066da97ffac639d3173281a8c1ca9.
> 
> Reverted the value from FKIE to NVD2, because the FKIE CVE database is
> not read properly by the cve-check script.
> 
> A lot of CVE entries are incomplete and incorrect. From what I can see, the
> majority of the CVEs are not correct with FKIE.
> 
> I can provide a simple example with CVE-2024-6119
> (https://nvd.nist.gov/vuln/detail/CVE-2024-6119).
> 
> On the official database the severity for this CVE, with CVSS Version 3.x, is: 7.5
> (HIGH)
> 
> On a build with the FKIE database we have the following result: sqlite3 nvdfkie_1-
> 1.db .dump | grep CVE-2024-6119
> 
> INSERT INTO NVD VALUES('CVE-2024-6119',replace('Issue summary:
> Applications performing certificate name checks
> (e.g., TLS\nclients checking server certificates) may attempt to read an invalid
> memory\naddress resulting in abnormal termination of t
> he application process.\n\nImpact summary: Abnormal termination of an
> application can a cause a denial of\nservice.
> \n\nApplications performing certificate name checks (e.g., TLS clients
> checking\nserver certificates)
> may attempt to read an invalid memory address when\ncomparing the expected
> name with an `otherName` subject alternative name of an\nX.509 certificate.
> This may result in an exception that terminates the\napplication program.\n\nNote
> that basic certificate chain validation (signatures, dates, ...)
> is not\naffected, the denial of service can occur only when the application
> also\nspecifies an expected DNS name, Email address or IP address.\n\n
> TLS servers rarely solicit client certificates, and even when they do,
> they\ngenerally don''t perform a name check against a reference identifier
> (expected\nidentity), but rather extract the presented identity after checking
> the\ncertificate chain.  So TLS servers are generally not affected
> and the severity\nof the issue is Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1
> and 3.0 are not affected by this issue.','\n',char(10))
> ,'0.0','0.0','0.0','2025-06-03T10:51:54.117','UNKNOWN',NULL);
> 
> You can see that the rode severity for CVSS Version 2.0, 3.0 and 4.0 are all set to
> '0.0', which is incorrect.
> 
> Now, with the NVD2 database: sqlite3 nvdcve_2-2.db .dump | grep CVE-2024-
> 6119
> 
> INSERT INTO NVD VALUES('CVE-2024-6119',replace('Issue summary:
> Applications performing certificate name checks
> (e.g., TLS\nclients checking server certificates) may attempt to read an invalid
> memory\naddress resulting in abnormal
> termination of the application process.\n\nImpact summary: Abnormal termination
> of an application can a cause a denial of\nservice.
> \n\nApplications performing certificate name checks (e.g., TLS clients
> checking\nserver certificates)
> may attempt to read an invalid memory address when\ncomparing the expected
> name with an `otherName`
> subject alternative name of an\nX.509 certificate. This may result in an exception
> that terminates
> the\napplication program.\n\nNote that basic certificate chain validation
> (signatures, dates, ...) is not\naffected,
> the denial of service can occur only when the application also\nspecifies an
> expected DNS name, Email address or IP address.
> \n\nTLS servers rarely solicit client certificates, and even when they do,
> they\ngenerally don''t perform a name check against a reference identifier
> (expected\nidentity), but rather extract the presented identity after checking
> the\ncertificate chain.
> So TLS servers are generally not affected and the severity\nof the issue is
> Moderate.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected
> by this issue.','\n',char(10))
> ,'0.0','7.5','0.0','2025-06-
> 03T10:51:54.117','NETWORK','CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H');
> 
> This is the correct severity for CVE-2024-6119.
> 
> The base issue does NOT come from the FKIE databse : https://github.com/fkie-
> cad/nvd-json-data-feeds/blob/main/CVE-2024/CVE-2024-61xx/CVE-2024-
> 6119.json
> 
> We can see for this CVE a "baseScore": 7.5.
> 
> It seems like poky is not reading the FKIE database correctly, so we revert the
> change to NVD2 with a working and complete database.
> 
> Note: I only gave the example of CVE-2024-6119 with CVSS example, but as you
> can see other fields are not correct either with "UNKNOWN" status.
> ---
>  meta/classes/cve-check.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
> index c63ebd56e1..2125eb5dd7 100644
> --- a/meta/classes/cve-check.bbclass
> +++ b/meta/classes/cve-check.bbclass
> @@ -32,7 +32,7 @@ CVE_PRODUCT ??= "${BPN}"
>  CVE_VERSION ??= "${PV}"
> 
>  # Possible database sources: NVD1, NVD2, FKIE
> -NVD_DB_VERSION ?= "FKIE"
> +NVD_DB_VERSION ?= "NVD2"
> 
>  # Use different file names for each database source, as they synchronize at
> different moments, so may be slightly different
>  CVE_CHECK_DB_FILENAME ?= "${@'nvdcve_2-2.db' if
> d.getVar('NVD_DB_VERSION') == 'NVD2' else 'nvdcve_1-3.db' if
> d.getVar('NVD_DB_VERSION') == 'NVD1' else 'nvdfkie_1-1.db'}"
> --
> 2.43.0

Tested and it worked for me.

Patches completely solved all FKIE issues I had.