Problem uploading BOM to OWASP Dependency Track about cdxgen HOT 9 CLOSED

No problem, happy to help.

It might not be the most elegant solution but this will return digest if it's already in hex format, or empty string otherwise.

Buffer.from(digest, 'hex').toString('hex')

from cdxgen.

It's working perfectly now. Thank you very much for the quick response and fix.

from cdxgen.

@sgarciaquobis That particular line looks ok. Can you share the language and package manager format so that I can check how sha 256 value gets constructed?

from cdxgen.

Thanks for the quick response. I was testing with Python using a requirements.txt file. In that line of code digest is 64 characters long, but when it's encoded in hexadecimal (hash variable) it's 96 characters.

For example:
digest (SHA-256) 0682b2eddab16151da5bd4ef38081e9b27f8eb33cd29baf41f4996d4e88e6e70
hash (hex) d3af366f679d75a6f5eb5e7575ae5b77879fdfcd3cd5ef5bdbb7fc79bdf771ddbd6da7f8d5fe3df7a7787bcf1ee9eef4

from cdxgen.

As per CycloneDX spec, the pattern should be an hex value with 64 or 96 or 128 characters long

pattern = ([a-fA-F0-9]{32})|([a-fA-F0-9]{40})|([a-fA-F0-9]{64})|([a-fA-F0-9]{96})|([a-fA-F0-9]{128})

https://cyclonedx.org/docs/1.2/#type_hashValue

I checked the reference implementation and they seem to be doing the same hex conversion here

Can you file a ticket in dependency track project and ask for some ideas?

from cdxgen.

I checked CycloneDX spec and understood the different types of hashes:

• MD5 32 characters
• SHA-1 40 characters
• SHA-256 64 characters
• SHA-512 128 characters

The problem is that after the hex conversion the string is longer. I'm not sure if dependency track should be doing the opposite conversion (hex to original hash) before trying to insert it into the database.

Anyway, using the reference implementations cyclonedx-python or cyclonedx-node the generated bom.xml files include the actual hash instead of the hex encoded version.

<component type="library"> <publisher>Kenneth Reitz</publisher> <name>requests</name> <version>2.25.0</version> <description>Python HTTP for Humans.</description> <hashes> <hash alg="MD5">2966d68a5a4e6832d967763d41f48d04</hash> <hash alg="SHA-256">e786fa28d8c9154e6a4de5d46a1d921b8749f8b74e28bde23768e5e16eece998</hash> </hashes> <licenses> <license> <name>Apache 2.0</name> </license> </licenses> <purl>pkg:pypi/[email protected]</purl> <modified>false</modified> </component>

<name>json5</name> <version>1.0.1</version> <description> <![CDATA[JSON for humans.]]> </description> <hashes> <hash alg="SHA-512">68a4b85908cf7a7471890b02f7730d7e3c7e9db1783c0758ce677fd49223f07633a9f6eef3a6de4ee3605c3ccf9275a4d27d2e0119727b0668e2cfbe112dfa3b</hash> </hashes>

UPDATE: I was doing some more testing and it seems that for Python projects it gathers the hashes from pypi.org and they are already in hexadecimal format (for example https://pypi.org/pypi/jsonschema/json)

from cdxgen.

Thanks @sgarciaquobis for the detailed investigation and explanation. I understood the problem now. Indeed the hex conversion is not required for python and possibly other languages too. Let me think of a way to implement this check and push an update.

from cdxgen.

Yes, used a logic similar to that along with a pattern regex. 2.2.7 should have the fix.

from cdxgen.

Thank you. Would appreciate if you could re-test and confirm if it works for you.

from cdxgen.