MySQL binary classifier should distinguish between MySQL Cluster (ndb) and MySQL

[westonsteimel]

What would you like to be added:

Currently, the MySQL binary classifiers don't distinguish between MySQL and MySQL (NDB) Cluster. The older versions of MySQL cluster do notdirectly align with the versions of MySQL they are built upon.

A specific example is MySQL Cluster v7.5.35. The MySQL Cluster version is of course 7.5.35 and the included MySQL version is 5.7.47

In this case, we observe the following version string embedded within the mysql binary:

strings ./bin/mysql | grep "5\.7"
5.7.47-ndb-7.5.35

So in this instance, it would ideally raise up two packages, one for mysql 5.7.47 (with a cpe like cpe:2.3:a:oracle:mysql), and another package for mysql-cluster 7.5.35 (with a cpe like cpe:2.3:a:oracle:mysql_cluster)

Why is this needed:
For an accurate sbom and later vulnerability matching, we need to be able to distinguish between the various mysql implementations

Additional context:
It may be that this ends up being complex enough to be separated into a separate cataloger similar to the jvm cataloger that was recently implemented

[westonsteimel]

It should also be noted that MySQL Cluster isn't currently detected at all by the binary classifier because the version string doesn't match the expected patterns, so this will currently result in false negatives on the vulnerability matching side in grype.

[westonsteimel]

It may be that with trying to use only the existing binary classifier approach that we need to identify another binary (apart from mysql) that can identify the cluster component (perhaps one of the ndb_* ones?) and then update the existing mysql classifier to handle parsing the mysql version component from the combined {mysql}-ndb-{cluster} pattern.

[spiffcs]

I removed discussion for this one since we talked about it on the live stream.

Dev note: if someone picks this up let's check out to see if this can fit in how we do the python binary:

syft/syft/pkg/cataloger/binary/classifiers.go

Lines 10 to 29 in 3267545

	{
	Class: "python-binary",
	FileGlob: "**/python*",
	EvidenceMatcher: evidenceMatchers(
	// try to find version information from libpython shared libraries
	sharedLibraryLookup(
	`^libpython[0-9]+(?:\.[0-9]+)+[a-z]?\.so.*$`,
	libpythonMatcher),
	// check for version information in the binary
	fileNameTemplateVersionMatcher(
	`(?:.*/|^)python(?P<version>[0-9]+(?:\.[0-9]+)+)$`,
	pythonVersionTemplate),
	),
	Package: "python",
	PURL: mustPURL("pkg:generic/python@version"),
	CPEs: []cpe.CPE{
	cpe.Must("cpe:2.3:a:python_software_foundation:python:*:*:*:*:*:*:*:*", cpe.NVDDictionaryLookupSource),
	cpe.Must("cpe:2.3:a:python:python:*:*:*:*:*:*:*:*", cpe.NVDDictionaryLookupSource),
	},
	},

In this case we do want to enhance the classifier to return two packages. We need to check for both mysql and the cluster component in order to be sure that we can surface both packages. This should be separate from the mysql approach.

[kzantow]

I was fairly confused during the discussion about what the specific issues are.

I'm reading this as: we should surface 2 packages from certain mysql binaries, and these particular mysql binaries do not match the current mysql matcher.

If the above is correct, I think this would be simple to do with a pair of classifiers that look for the right patterns and return appropriate mysql and mysql_cluster, respectively, rather than trying to shoehorn this flavor of mysql into the existing mysql classifier and/or modify the binary cataloger to return multiple packages from these.