Open loosebazooka opened 3 years ago
It seems the cargo module also has this bug, via the readCheckSum
helper, that just SHA-1s the string contents it's given. In the cargo module this is just called with the dep ID, instead of any sort of actual module contents:
The composer module also has a copy of the readCheckSum
helper, which gets called with the packageUrl
and stuffed into the module checksum:
This seems like a pretty egregious bug to me, since people might see the module checksum value and come to believe it represents actual content digests, instead of just the digest of a string they already have. When verifying the sbom, the actual module content digest won't match the module name digest reported in the sbom.
Even worse, if someone manages to push new module contents with the same name, the checksum reported in the sbom will remain the same and consumers of the sbom will be none the wiser.
This issue seems to be endemic to this codebase. I'd suggest taking a closer look at how these checksums are collected and reported, and even better having some verification or testing framework in place to ensure that the checksum reported matches the module contents. If sboms can't be reliably reported and verified, they're not going to be of much practical use to anybody.
Summary
https://github.com/spdx/spdx-sbom-generator/blob/main/pkg/modules/javamaven/decoder.go#L173
the artifact hash should not be on the name of the module. For example the artifact
com.google.guava:guava:30.1.1-jre
should have a sha1 of https://repo1.maven.org/maven2/com/google/guava/guava/30.1.1-jre/guava-30.1.1-jre-javadoc.jar.sha1