fix: use full namespaced name for db search PURLs#3531
Conversation
| // Without this, a search for a namespaced PURL only used purl.Name and silently | ||
| // failed to match. This mirrors the same reconstruction the openvex build | ||
| // transformer performs (grype/db/v6/build/transformers/openvex). | ||
| func packageNameFromPURL(purl *packageurl.PackageURL) string { |
There was a problem hiding this comment.
Hi @arpitjain099 -- we talked about this on the livestream and the consensus is we should handle PURLs the same as when scanning here. There are a number of other nuances that occur when you run grype against a PURL compared to when you specify a PURL here. The simple solution would be to use the SBOM decoder to get a package, which will have all the information from the PURL as we expect it in a package. After that, we probably want to use the PackageNames function to get all the search names for a given package. This will result in correctly searching for NPM, Java, Golang, and other packages and avoid these functions drifting
kzantow
left a comment
kzantow
left a comment
There was a problem hiding this comment.
Per the comment we should convert PURLs to packages and use the PackageNames function to search the same way matching will
grype db search --pkg built the package specifier straight from the raw PURL fields, using only purl.Name. For ecosystems that carry part of the name in the PURL namespace this dropped the rest of the name, so the search never matched. A golang module PURL like pkg:golang/github.com/gin-gonic/gin was searched as just "gin" instead of github.com/gin-gonic/gin. Decode the PURL into a package through the same provider path used when scanning, then ask the DB name resolver (name.PackageNames) for the search names. This reconstructs golang module paths, npm scopes, and Maven group:artifact coordinates, and also applies ecosystem-specific normalization such as PEP 503 for Python, without this command reimplementing any of it. The ecosystem is taken from the decoded syft package type, which the search layer already normalizes. Fixes anchore#3508 Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
arpitjain099
force-pushed
the
chore/db-search-purl-module-path
branch
from
ea373b3 to
9a7efc5
Compare
|
Thanks @kzantow, that makes a lot of sense. I reworked it to go through the same path as scanning: decode the PURL into a package via |
2 participants
Fixes #3508.
grype db search --pkgwith a golang PURL doesn't match because the package specifier is built frompurl.Nameonly. For ecosystems that carry part of the name in the PURL namespace, that drops the rest of the name. Sopkg:golang/github.com/gin-gonic/gingets searched as justgin, and nothing matches (the DB keys the record under the full module pathgithub.qkg1.top/gin-gonic/gin).This adds an ecosystem-aware
packageNameFromPURLinPostLoadthat reconstructs the stored name:namespace/name(e.g.github.com/gin-gonic/gin,@babel/core)groupId:artifactIdpurl.Name(unchanged behavior for flat-namespaced ecosystems)It's the same reconstruction the openvex build transformer already does (
grype/db/v6/build/transformers/openvex), so the search side and the data side now agree on the name. I extended it to cover golang since that's what the issue hit.Testing
Added table cases to
TestDBSearchPackagesPostLoadfor the golang module path, npm scope, and Maven group:artifact mappings (the plain-name fallback was already covered).