Skip to content
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

Revert "feat(checker): add debianutils (#3390)" #3633

Closed
wants to merge 1 commit into from

Conversation

ffontaine
Copy link
Contributor

This reverts commit a4612c8 as there is no CVEs related to debianutils:
https://www.cvedetails.com/product-search.php?vendor_id=0&search=debianutils.

@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a168298) 77.76% compared to head (e5f0042) 78.19%.
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3633      +/-   ##
==========================================
+ Coverage   77.76%   78.19%   +0.42%     
==========================================
  Files         781      781              
  Lines       11700    11700              
  Branches     1369     1369              
==========================================
+ Hits         9099     9149      +50     
+ Misses       2183     2130      -53     
- Partials      418      421       +3     
Flag Coverage Δ
win-longtests 78.19% <100.00%> (+0.42%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@terriko
Copy link
Contributor

terriko commented Dec 19, 2023

I think I'm going to keep this one because so many people have been interested in using cve-bin-tool for composition analysis and generating sboms, which means those users would still want to find debianutils even if there's no CVEs in it. (I still don't think we're great as a composition analysis tool, but I can't deny that people are using us for this purpose on occasion and I'm not sure too many of the others have the same range of signatures so they could legit be getting additional results they're not finding elsewhere.)

That said, I wonder if we should have have some logic so any checker that has no CVEs associated with it doesn't run during cve scans, only during sbom generation or something? I'll open an issue for people to brainstorm on it.

@ffontaine
Copy link
Contributor Author

I do understand your point.
If such kind of checkers is kept, it means that the solution designed for #3628 will have to explicitly handle such of kind of checkers.

Moreover, it also means that if for some reason in the future, a CVE is allocated for debianutils but with a different CPE ID that the one that was "randomly" chosen in the checker (e.g. debianutils_project:debianutils instead of debian:debianutils), cve-bin-tool will wrongly report them no CVEs affect debianutils.
So, I would agree to not run those "incomplete" checkers by default even for SBOM generation.

@terriko
Copy link
Contributor

terriko commented Dec 20, 2023

Yeah, I'm thinking maybe if we don't known a VENDOR_PRODUCT string then maybe we could set it to [] or something consistent and specifically invalid to help cve-bin-tool (and the currently imaginary validation script) to do the right thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants