Report only those fixed versions that are greater than the affected version

[johnmhoran]

The VulnerableCode UI and API currently report a full set of all fixed versions of a package that are related directly or indirectly to a particular affected version, including fixed versions whose version number is less than the affected version number. This seems potentially confusing to users and inaccurately identifies package versions that a user should consider to address an identified vulnerability.

It would be more useful (and accurate) if the VulnerableCode UI and API reported only those fixed versions that are greater than the particular affected version at issue. I've attached a .xlsx file containing examples of fixed-version mismatches.

See also

• Affected vs. fixed packages #863
• process_advisories should check if fixed version lies within the affected_version_range #630

examples-of-affected-vs-fixed-version-mismatches-v0.01.xlsx

[DennisClark]

good idea

[johnmhoran]

My push is still a work-in-progress and retains many print statements for ongoing exploration of the data and functions. The terminal displays some relevant high-level data about the affected package, the vulns and the fixing packages.

Working on the Packages class in models.py, I've created a function get_fixing_packages(self) in which Prefetch takes the list of vulns affecting the current package, retrieves a list of the fixing packages for each vuln, and assigns the result to a custom attribute, filtered_fixed_packages, that we can call when needed.

We also have the very beginnings of a function assign_univers_version(self, fixing_pkg), which identifies which univers version applies to the two packages to be compared (self and a fixing package), evaluates whether the fixing_pkg version is > than the target affected package, and returns True or False. I need to add more univers versions to the dictionary; and still need to check which fixing version is closest to (but greater than) the affected version.

All of this is conveyed to the Jinja2 template (package_details.html) with this context key-value pair in the PackageDetails class in views.py: context["get_fixing_packages"] = package.get_fixing_packages -- called in the Jinja2 template with {% if pkg in get_fixing_packages %}.

I'm using some red and green colors in the Package details template to highlight the test data and have included a short explanation in the template for the time being. These 4 example searches (all maven for now) illustrate the fixing packages we start with (red) and the filtering we do to match type, namespace etc. and discard "backport" versions (green).

pkg:maven/net.minidev/json-smart@2.3
pkg:maven/org.apache.hadoop/hadoop-common@3.2.2
pkg:maven/org.springframework/spring-webmvc@4.1.0
pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.1

[johnmhoran]

More to do, including cleaning up the code, updating existing tests and adding a few new tests for the latest work, but this does look cleaner/less cluttered with data. In addition, I've changed all instances of PURL to purl. Is that what we want?

[pombredanne]

Here are some suggestion for your consideration:

• The "closest fixed by packages" should just be "Fixed by" IMHO. This is simpler and this is the concept exactly anyway, so no need to get "closest". The fact we have purl makes it obvious these are packages. Or we could even go as "Fixed by versions" and only list versions (and link to purls), to be discussed.

• "Vulnerabilities: 5 ?" may be more explicit as "Other vulnerabilities" or "Affected by 5 other vulnerabilities ?"

• The text popup behind the ❓ question mark may be better as "This version is affected by these other vulnerabilities:"

• "Closest non-vulnerable purl" may be better as simply "Non-vulnerable version", and were we would display only the version, yet link to the purl? (the API would get the purl)

• In the same way, "Latest non-vulnerable purl" may be better as "Latest non-vulnerable version", and were we would display only the version, yet link to the purl? (the API would get the purl too). Also we could consider the latest minor version (here some version 9.x) vs. the latest major version( here some version 10.x) separately, as packages with multiple version lines like Tomcat would benefit from this.

In general I feel avoiding the visual repetition of the purl everywhere when only the version changed would simplify the display.

Also what happens when:

• there is no other vulnerabilities?
• there is no package fixing a vulnerability?
• there is no latest vulnerable?

[pombredanne]

I've changed all instances of PURL to purl.

I think this is something we need to decide and apply across all projects and docs uniformly. @adaaaam @DennisClark @mjherzog ... what's your take?

• PURL, purl, Purl, pURL?
• package URL, Package URL, package-url, Package-URL, package-URL?

[adaaaam]

i thought we previously agreed on Package-URL or PURL... we need to pick one and be consistent going forward.

[DennisClark]

I agree with Adam on this one:
long-form: Package-URL
short-form: PURL

although, I am open to strong arguments in favor of purl for the short-form.

[mjherzog]

+1 for PURL and Package-URL; "purl" gets lost anytime you see it in a sentence. This is not like Package vs package where the core term is generic out in the world