intel / cve-bin-tool

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions.
https://cve-bin-tool.readthedocs.io/en/latest/
GNU General Public License v3.0
1.19k stars 457 forks source link

feat: Documentation and plugin system for parsers #4200

Closed pdxjohnny closed 3 months ago

pdxjohnny commented 3 months ago

image

pdxjohnny commented 3 months ago

@terriko This is ready for review when you have time. Thank you in advance :)

terriko commented 3 months ago

Was there a specific motivation for this?

I ask because our current plugin system is the thing blocking us from moving to pyproject.toml from setup.py. And honestly, that's not a thing we need but it would make a bunch of our config go into that file so we don't have to have quite as many separate configs for our linters. So I'd been wondering if we should refactor away from those plugins next time we do a big refactor. Do you know of anyone supporting out of tree stuff that this would affect?

I love refactoring the parsers to be more atomic in that they actually know what files they're scanning for, and I love the better documentation. But I"m wondering if we should rethink the plugins now before we add more of them, I guess?

terriko commented 3 months ago

Adding: Got some more info on the use case from @pdxjohnny and I agree that this is probably the best solution. I'll be back to do a more nitpicky code review later.

pdxjohnny commented 3 months ago

I will start on un-entrypoint-zing in-tree checkers so we can move to pyproject.toml as a seperate PR, then we can have it load entrypoints from out-of-tree plugins in addition to in-tree stuff.

pdxjohnny commented 3 months ago

Woohoo thank you!!!