Improve hash support

[stevespringett]

Hash support needs serious improvement. It appears that hashes are derived from the package itself, rather than calculating them. If the package didn't have a hash, it doesn't show up in the resulting bom. In addition, if a components package does have a hash, its rare that it will contain more than one (sha1, sha-512, but not both for example).

Need to investigate the ability to generate all supported hashes for packages and ensure that unmodified packages have the same hash value as stated in the package manifest. If a hash is generated that doesn't match what's in the package, then flip the modified element to true.

[sophiewigmore]

Hi there!

I am also having a problem with hash support that I think is related to this issue.

When I use the cyclonedx-bom CLI tool against a simple Node.js app that contains node modules, the resulting BOM file does not contain any hash content for the node modules if the Node Engine version is v15.X.X or v16.X.X. I'm not sure if the mechanism for surfacing this information has changed in these versions, but collecting the hash metadata definitely does not work for those versions

Edit: It appears that in Node Engine v15, the NPM version inside changed which includes a new package-lock.json format. The package.json files of each node module also appear to not contain the hashes, but the top level package.json does.

[sophiewigmore]

Additionally, it looks like the hashes included come from the _shasum field inside of each node module's package.json. What is the rationale for using this field rather than the integrity field from the top level package-lock.json?

[jkowalleck]

this feature was implemented in the NPM flavour of this package:
https://github.com/CycloneDX/cyclonedx-node-npm/