fix: handle unknown values in metric_finder (Fixes #4578)

[vedpawar2254]

Fixes #4578 ([CVEDB] Why does the function metric_finder returns unknown or a ### metrics_id)

Added "UNKNOWN" Metric
Implemented a method (ensure_unknown_metric) to ensure it exists
and updated the metric_finder function

I removed the commits from the other PR, you can check this one out while i'll look into why the tests for #4654 are failing

Thanks and lemme know if we need to change anything

[terriko]

Looks like you're failing a couple of lint checks because there's some whitespace on a blank line. I've added a comment where I think it's happening, but the best way to be sure it's fixed is to run black cve_bin_tool/cvedb.py then check your file back in and push it to the PR branch.

Here's some more info on our linters in case you've never run those before:
https://github.com/intel/cve-bin-tool/blob/main/CONTRIBUTING.md#running-linters

It's also complaining about the PR title because it doesn't conform to the commit message format we use, which is https://www.conventionalcommits.org/ -- I'll change the title for you now so it should pass next time but the linter won't run again until you update the branch.

[terriko]

The blank line here has some extra spaces or a tab in it.

[vedpawar2254]

Hi @terriko , it should be good now, my vs code extensions are messing with me 😅, also there are some broken links in MANUAL.md as pointed out by @Molkree, i'll raise a pr to fix it, should i also create a issue.
I think I'll also checkout the other docs to see if there are any broken links or smtg

[vedpawar2254]

@terriko can you see why the test case is failing, i'd appreciate it

[terriko]

Not sure what's happening there off the top of my head. I'm going to re-run the failing test because we've had a bunch of weirdness with the cache, but I'll flag this so I come back and look at it if it doesn't pass.

[jloehel]

Just my 2¢, to move this forward. @terriko I hope it's possible to merge it soon.

[jloehel]

I would use UNKNOWN_METRIC_ID just to avoid magic numbers it increases the readability.

[krushndayshmookh]

+1

[jloehel]

Why not moving this to populate_metrics and ensure that the table metrics gets also monitored for changes like in example cve_range in get_cvelist_if_stale.

[krushndayshmookh]

Patching myself here to follow up with further conversations.

[terriko]

See jloehe's comments. I think at least the UNKNOWN_METRIC_ID change would be good here.

[vedpawar2254]

@terriko, i changed the UNKNOWN_METRIC_ID but i am not getting what the other change should be, can you help me out a lil here

[jloehel]

I mean populate_metrics ensures that the metric ids for EPSS, CVSS .. exist. Why not moving the logic of the new function ensure_unknown_metric there?

cve-bin-tool/cve_bin_tool/cvedb.py

Lines 616 to 630 in 0c481e4

	def populate_metrics(self):
	"""Adding data to metric table."""
	cursor = self.db_open_and_get_cursor()
	# Insert a row without specifying cve_metrics_id
	insert_metrics = self.INSERT_QUERIES["insert_metrics"]
	data = [
	(EPSS_METRIC_ID, "EPSS"),
	(CVSS_2_METRIC_ID, "CVSS-2"),
	(CVSS_3_METRIC_ID, "CVSS-3"),
	]
	# Execute the insert query for each row
	for row in data:
	cursor.execute(insert_metrics, row)
	self.connection.commit()
	self.db_close()

That means add UNKNOWN_METRIC_ID to the data.

But for this it's also necessary to change the logic for when an update (populate call) is necessary. Right now it's necessary if :

1. the db file does not exist
2. the db file is older than 24 hours
3. the schemas for cve_severity, cve_range and cve_exploited have changed

A fourth condition is necessary to trigger the update if the METRIC IDs have changed.

[terriko]

I think @jloehel has the right idea here, but since this PR will at least give us a reasonable working fix right now, I'm going to go ahead and merge it as is and open a new issue with the recommended refactor.

[vedpawar2254]

Ok @terriko, thanks. I was actually working on that 🫣