openvex / go-vex

Go module to generate and transform VEX documents
Apache License 2.0
33 stars 15 forks source link

VEX.CanonicalHash function colon delimiters: 1 extra, 1 missing #59

Closed p-ssanders closed 11 months ago

p-ssanders commented 12 months ago

Hello! As I was re-implementing the VEX.CanonicalHash function in Java for jvex to achieve consistent document ID generation between libraries, I noticed the VEX.CanonicalHash algorithm implementation includes a superfluous colon delimiter, and misses a necessary colon delimiter. It sounds trivial, but these delimiters change the entire hash.

Extra Colon Delimiter The entry point of the cstringFromComponent function appends the Component's ID with a leading colon delimiter. The return value of this function is then appended to the caller's cString with another leading colon.

https://github.com/openvex/go-vex/blob/23adb1b9dbecd9547d6b9794a7cd221d7966c242/pkg/vex/vex.go#L250 https://github.com/openvex/go-vex/blob/23adb1b9dbecd9547d6b9794a7cd221d7966c242/pkg/vex/vex.go#L235

The result is a cString that includes two colon delimiters like the following, when there should only be one:

1673917636::pkg:oci/git@sha256

Missing Colon Delimiter The cstringFromVulnerability function creates a string of colon-delimited vulnerabilities, but does not include a leading colon delimiter. The return value is then appended to the caller's cString without a colon delimiter.

https://github.com/openvex/go-vex/blob/23adb1b9dbecd9547d6b9794a7cd221d7966c242/pkg/vex/vex.go#L273 https://github.com/openvex/go-vex/blob/23adb1b9dbecd9547d6b9794a7cd221d7966c242/pkg/vex/vex.go#L214

The result is no colon delimiter between the vulnerability alias's string (GHSA-jfh8-c2jp-5v3q) and the vulnerability name (CVE-2021-44228)

https://nvd.nist.gov/vuln/detail/CVE-2021-44228:CVE-2021-44228GHSA-jfh8-c2jp-5v3q:not_affected