search

aboutcode-org / vulnerablecode

A free and open vulnerabilities database and the packages they impact. And the tools to aggregate and correlate these vulnerabilities. Sponsored by NLnet https://nlnet.nl/project/vulnerabilitydatabase/ for https://www.aboutcode.org/ Chat at https://gitter.im/aboutcode-org/vulnerablecode Docs at https://vulnerablecode.readthedocs.org/
https://public.vulnerablecode.io
Apache License 2.0
526 stars 197 forks source link

What to expect from ``plain_purl`` functionality ? #1255

Open TG1999 opened 1 year ago

TG1999 commented 1 year ago

If we have 3 purls, pkg:npm/foo/bar@1.2 , pkg:npm/foo/bar@1.2?baz=jon, pkg:npm/foo/bar@1.2?baz=doe and you ask for plain purls only with this input pkg:npm/foo/bar@1.2?baz=jondoe, what should I send as output here all 3 purls or the purl without qualifiers?

TG1999 commented 1 year ago

Case 1: A vulnerable package without qualifiers or subpath is inside DB and input is purl with qualifiers and subpath Case 2: A vulnerable package with qualifiers and subpath is inside DB and input is purl without qualifiers and subpath Case 3: Multiple vulnerable package with different qualifiers and subpath and input is purl without qualifiers and subpath Case 4: Multiple vulnerable package with different qualifiers and subpath and input is purl with qualifiers and subpath that we do not have in DB

TG1999 commented 10 months ago

@pombredanne suggested that we should have 2 functionalities lookup and search.

lookup should only return data when it's an exact match in the db for what the user searched for and search should support fuzzy matching and return more than what it needs.

TG1999 commented 10 months ago

1st option: The client should do a filtering on their purls and we will give an exact match on purls.

2nd option: The client sends the purl with or without qualifiers and VCIO makes a choice to look with or without qualifiers.