You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #1287, I noticed that when the results of a UI Package search query for a PURL with a qualifier include a PURL with a qualifier, the PURL displayed in the Package search results list uses '?' as the separator indicating that a qualifier follows, but the actual URL uses the ASCII-encoded '%3F'. Clicking such a link takes the user to the intended Package details page for the PURL with a qualifier.
However, the URLs displayed on the Package details page for any PURL with a qualifier use '?' rather than '%3F'. As a result, clicking such a link does not take the user to the page for the PURL with the qualifier. Instead, VCIO disregards that portion of the URL that starts with '?' -- if the PURL string up to the '?' identifies a Package in the database, clicking that link takes the user to that PURL without a qualifier, but if there is no such PURL in the database, a page-not-found/404 is returned instead.
A quick check of the API suggests there is no similar issue with the URL or PURL data there but this needs a more thorough check to be certain.
When identifying whether a PURL with a qualifier that is affected by a vulnerability is fixed by a subsequent PURL, must that subsequent PURL include the same qualifier in order to be treated as a fixed-by PURL for that affected PURL?
Regarding the API, a query for 'pkg:nginx/nginx@0.8.9?os=windows' returns fixed_packages data that includes a matching qualifier and a 'resource_url' with a properly encoded qualifier, but the entries for 'next_non_vulnerable_version' and 'latest_non_vulnerable_version' display only the version. See https://public.vulnerablecode.io/api/packages/bulk_search?format=api
The Package details page URL displays are similarly limited to the version.
Perhaps we should modify that API and UI data to include a full PURL rather than just the version to clarify exactly what data is being identified.
For the time being I've replaced '?' with '%3F' while working on #1287 since the correct PURL and URL are important in matching affected with fixed-by Packages. The initial solution uses a custom filter to convert the incoming PackageURL object to a string, replaces '?' with '%3F' and returns the modified string. Seems to provide the results we want. There may be a more Pythonic solution (e.g., in models.py or views.py) but that has eluded me so far.
We still have open questions ^ re whether for our purposes a fixed-by PURL must match both qualifiers and subpath of the affected PURL. I think the answer is Yes but could be mistaken. Feedback is welcome and encouraged. ;-)
While working on #1287, I noticed that when the results of a UI Package search query for a PURL with a qualifier include a PURL with a qualifier, the PURL displayed in the Package search results list uses '?' as the separator indicating that a qualifier follows, but the actual URL uses the ASCII-encoded '%3F'. Clicking such a link takes the user to the intended Package details page for the PURL with a qualifier.
However, the URLs displayed on the Package details page for any PURL with a qualifier use '?' rather than '%3F'. As a result, clicking such a link does not take the user to the page for the PURL with the qualifier. Instead, VCIO disregards that portion of the URL that starts with '?' -- if the PURL string up to the '?' identifies a Package in the database, clicking that link takes the user to that PURL without a qualifier, but if there is no such PURL in the database, a page-not-found/404 is returned instead.
A quick check of the API suggests there is no similar issue with the URL or PURL data there but this needs a more thorough check to be certain.
Related issues:
The text was updated successfully, but these errors were encountered: