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

Discussion: expat and libexpect conflict on checkers #1694

Closed
snosratiershad opened this issue Jun 8, 2022 · 3 comments · Fixed by #3256
Closed

Discussion: expat and libexpect conflict on checkers #1694

snosratiershad opened this issue Jun 8, 2022 · 3 comments · Fixed by #3256

Comments

@snosratiershad
Copy link
Contributor

snosratiershad commented Jun 8, 2022

As discussed in this issue, we decided to modify CONTAINS_PATTERNS for expat.
but the checker of cve_bin_tool.checkers.expat.ExpatChecker isn't directly related to expat binaries.
listed CONTAINS_PATTERNS (example: "requested feature requires XML_DTD support in Expat") and VENDER_PRODUCT (example: ("libexpat_project", "libexpat")) are related to libexpat, which is included in expat packages binaries in all of RPM repositories also, but not in any DEB repository (in DEB repos libexpat1 has it's own package).
DEB packages only are only providing the xmlfw (expat terminal utility) with a dependency to a specific version of libexpat.
However the CVE links listed in docstring of checker module is also related to libexpect.

Should we modify the ExpatChecker to exact parameters of exact packages binaries and add another checker named LibexpatChecker?
or forgot about expat and implement a checker only for libexpat?

@terriko
Copy link
Contributor

terriko commented Jun 16, 2022

I think the expat checker has always been about libexpat. It's one that was written long before this was open sourced, back when we were mostly looking for compiled-in libraries. I'd say we should just change the docstrings to make it more clear but not worry about adding separate checkers for the console utilities unless someone really wants to. Do the console binaries even have separate CVEs that would be worth finding? The library is where the bulk of the work is done so I'd assume this is where the significant CVEs are most likely to occur.

We could potentially change the checker name too, but that would be a breaking change for folk who might have it explicitly enabled or disabled, so I wouldn't bother with that unless this is actually causing a problem for someone. We could maybe consider doing that change at some time when we're making bigger breaking changes to the interface, but I'm not expecting any of those for the next release at this time.

@snosratiershad
Copy link
Contributor Author

Thanks @terriko, I understand.

@ffontaine
Copy link
Contributor

It should be noted that the only valid CPE ID for expat is libexpat_project:libexpat, libexpat:expat is not found in NVD NIST database: #2515

ffontaine added a commit to ffontaine/cve-bin-tool that referenced this issue Aug 15, 2023
Rename expat checker to libexpat to make it more clear that the checker
extracts libexpat version

Fix intel#1694

Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine added a commit to ffontaine/cve-bin-tool that referenced this issue Aug 16, 2023
Rename expat checker to libexpat to make it more clear that the checker
extracts libexpat version

Fix intel#1694

Signed-off-by: Fabrice Fontaine <[email protected]>
terriko pushed a commit that referenced this issue Aug 17, 2023
Rename expat checker to libexpat to make it more clear that the checker
extracts libexpat version

Fix #1694

Signed-off-by: Fabrice Fontaine <[email protected]>
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 a pull request may close this issue.

3 participants