New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent invalid CPE field values #514
Conversation
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Benchmark Test ResultsBenchmark results from the latest changes vs base branch
|
@@ -129,6 +133,8 @@ func candidateVendors(p pkg.Package) []string { | |||
// generate sub-selections of each candidate based on separators (e.g. jenkins-ci -> [jenkins, jenkins-ci]) | |||
addAllSubSelections(vendors) | |||
|
|||
vendors.removeByCondition(invalidCPEValue) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would all clearly work for the case where there's as :
in the vendor... are there other fields that could contain colons or other characters that would result in these being invalid? Would a better approach be validating the CPE can be re-parsed later on? Would that be too slow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's interesting! I'm up for that approach. If I understand correctly: before returning all generated CPEs, we'd test each one by serializing it and then deserializing it. Is that right?
@wagoodman Curious for your thoughts here, too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... I just remembered we have benchmark tests that could show us a substantial change in performance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attempted in 1a51bd5 — let me know what you think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach much better... instead of covering the single case of :
we're getting to the root problem of "don't allow CPEs that will never work" 👍
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: naming... fieldCandidateCondition
> filterFieldCandidateFn
👍
Also, adding the optional conditions to value()
and list()
is very nice 🚀
* main: Add vendor + product known good CPE field values (#517) Add SBOM to releases (#500) Add announcement for KubeCon meetup (#515) Prevent invalid CPE field values (#514) Filter out CPE product candidates that are asterisks (#513) Use Anchore fork of packageurl lib without replace directive (#512) update log file permissions to 0644 (#511) Signed-off-by: Christopher Angelo Phillips <christopher.phillips@anchore.com>
* Fix CPE set comparison mismatch Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Add failing test to assert CPE generation excludes URLs Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Add removeByCondition method to fieldCandidateSet Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Prevent invalid CPE values for products and vendors Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Introduce removeWhere and rename filter to condition Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Refactor fieldCandidateSet and condition logic Signed-off-by: Dan Luhring <dan.luhring@anchore.com> * Move CPE parsing filter to end of CPE generation Signed-off-by: Dan Luhring <dan.luhring@anchore.com>
This is the second half of the solution to anchore/grype#417 (the first half being anchore/grype#425).
This PR prevents CPEs from being generated where the product or vendor field contains URL-like strings (e.g.
http://jcp_org/en/jsr/detail?id=173
), or more generically, invalid string values.This PR takes the approach of considering any field value that contains a colon (
:
) to be invalid, since colons are the delimiter of CPE fields, and this covers the case of URLs that contain substrings likehttp://
.