Open keshav-space opened 11 months ago
Adding for completeness
>>> original = PackageURL.from_string('pkg:maven/org.apache.logging.log4j/log4j@2.16.0')
>>> patched = PackageURL.from_string('pkg:maven/org.apache.logging.log4j/log4j@2.16.0-patched')
>>> affected_version_range = VersionRange.from_string('vers:maven/>2|<3')
>>> MavenVersion(original.version) in affected_version_range
True
>>> MavenVersion(patched.version) in affected_version_range
True
Perhaps the affected version range will have to be changed on the vulnerablecode client to exclude -patched
>>> affected_version_range = VersionRange.from_string('vers:maven/>2|<3|!=2.16.0-patched')
>>> MavenVersion(original.version) in affected_version_range
True
>>> MavenVersion(patched.version) in affected_version_range
False
This could be achieved by having a user-created advisory with higher confidence.
Suppose there is a CVE that affects the package
pkg:maven/org.apache.logging.log4j/log4j@2.16.0
and there is no official fix available. In this scenario, I have two options:Patch the library locally to create a modified version, such as
pkg:maven/org.apache.logging.log4j/log4j@2.16.0-patched
but do not publish it publicly.Patch the library and then republish it to maven under new namespace, like
pkg:maven/com.example/org.apache.logging.log4j@2.16.0-patched
The second option, for all practical purposes, creates a separate package. However, if I choose the first option and at a later stage, I'm trying to identify vulnerable packages in my project,
pkg:maven/org.apache.logging.log4j/log4j@2.16.0-patched
should not be reported as vulnerable to the same CVE.