Some package entries have wrong package metadata

[dlebelcimmi]

We use sbom4python to construct an sbom for our product. Our environment was built around python 3.9 and the sbom generation seemed correct. Now that we upgraded our environment to python 3.12, we now noticed an issue with some packages. Especially numpy and scipy.

The sbom entries for these packages are replaced by other packages when running sbom4python in python 3.12

numpy becomes GCC runtime library
scipy becomes libquadmath

In fact, these are sub dependencies of the related packages. The output of "pip show numpy" displays different metadata attributes of the package (Name:, Version:, etc.). But for these big packages, pip show also outputs some information about sub dependencies.

In python 3.9, the sub dependencies metadata output were indented. But in python 3.12, the metadata are not indented anymore and are then mingled at the same level. For example, lets compare the output of this command using different versions of python:

(python 3.9)

> pip show scipy | findstr Name:

Name: scipy
        Name: OpenBLAS
        Name: LAPACK
        Name: GCC runtime library
        Name: libquadmath

(python 3.12)

> pip show scipy | findstr Name:

Name: scipy
Name: OpenBLAS
Name: LAPACK
Name: GCC runtime library
Name: libquadmath

sbom4python uses pip show to recover packages metadata and build a metadata dictionnary by parsing the output of pip show.

sbom4python/sbom4python/scanner.py

Line 245 in f377631

out = self.run_program(f"pip show {module}")

sbom4python/sbom4python/scanner.py

Line 252 in f377631

if (len(entry) == 2) and (entry[1] and not (entry[1].isspace())):

Since the entries for the displayed package and the subpackage are at the same level in python 3.12, then all entries of a subpackage that is already in the dictionary end up overwritting the current package entry. The last sub package described by pip show take precedence and replace the actual package description. Furthermore, some metadata attributes are mingled in the final metadata.

For these reasons, I would urge you to replace the recovery of metadata by a more structured and robust approach (#17).

[anthonyharrison]

I am currently working on addressing #17.