grype db status doesn't always check the db's checksum and validity

[luhring]

What happened:

A coworker was getting this output from Grype:

1 error occurred:
	* failed to load vulnerability db: unable to get namespaces from store: database disk image is malformed (11)

This error is originating from the sqlite driver, and it looks like other Grype users encounter it on occasion, e.g. #1150. The underlying cause is that the database has been corrupted (somehow).

But... I asked them to run grype db status, and here's what they got:

grype db status
Location:  /Users/<snip>/Library/Caches/grype/db/5
Built:     2024-01-04 01:26:41 +0000 UTC
Schema:    5
Checksum:  sha256:d853702af304b86fb2180b83d8fcef1ddf7f6578df8216cfe427d42abb2b5d26
Status:    valid

This could be way more helpful than it currently is, especially when debugging database issues like this one.

It's not actually checking the real database's checksum, or the real database's validity. It's just reporting what's in the metadata JSON file. This makes it harder to find out why Grype isn't working correctly, when it's a database issue. This is frustrating for users, too, because such database issues usually render Grype inoperable until you run grype db delete && grype db update or something (which the average user doesn't know about).

What you expected to happen:

From talking on Anchore Slack, it sounds like the config check used during the execution of grype db status should become a non-conditional, "always do the check" execution path.

grype/grype/db/curator.go

Line 323 in d5ced7f

if c.validateByHashOnGet {

How to reproduce it (as minimally and precisely as possible):

$ echo "booboo" > ~/Library/Caches/grype/db/5/vulnerability.db
$ grype db status
Location:  /Users/dan/Library/Caches/grype/db/5
Built:     2024-01-04 01:26:41 +0000 UTC
Schema:    5
Checksum:  sha256:d853702af304b86fb2180b83d8fcef1ddf7f6578df8216cfe427d42abb2b5d26
Status:    valid

Anything else we need to know?:

Environment:

• Output of grype version:
• OS (e.g: cat /etc/os-release or similar):

[tgerla]

Thanks @luhring, we'll add this to the backlog.