GSoC 2022 Ideas / Brainstorming thread

[terriko]

GSoC 2022 has now been announced!

This thread is open for brainstorming ideas for GSoC 2022 projects. They can be either 175hr or 350hr ideas. GSoC is open to anyone over 18 now, not only students,, and the timing is more flexible than it used to be.

Note that this is a brainstorming thread so it's going to include even things that are infeasible, low priority, or have potentially blocking issues. The point is to have a pool of ideas we can combine to maybe make some reasonable projects; they can be narrowed down further in January or so. When ideas have gotten past the brainstorming stage to "maybe this is a doable project?" stage we'll try to break them out into separate issues.

• UI for CVE-Bin-Tool -- currently we're all command line
• Windows package manager data (the way we handle linux/python package lists)
• Other package managers: npm, rust, java -- some of these exist, maybe calling existing software to get results?
• Training package: training people to use/develop CVE Binary Tool (note: needs to have enough code to qualify for google summer of code, but we could look in to participating in season of docs or outreachy instead)
• Internationalization: but only if we can find some users interested in using/testing the translations
• Improve code coverage. See GSoC 2022 idea: get test coverage to 95% (stretch goal, 100%) #1525

[terriko]

• cve-bin-tool as a service (what would that even mean?)
• other formats and integrations (e.g. with Tern, with AboutCode, others?)

[terriko]

• improve type checking (and integrate automatic tools in CI for this)

[anthonyharrison]

• Use additional or alternative vulnerability databases e.g https://osv.dev/

[ashok-arora]

cve-bin-tool as a service (what would that even mean?)

@terriko How about a website (written in Flask and HTML/CSS) where the user can upload the binary and then the report is displayed (with options to download in a specific format)?

[terriko]

@ashok-arora I don't think that'll work for GSoC. A service like that requires pretty extensive security validation, testing, and an ongoing maintenance commitment if I wanted to release it following Intel's security guidelines. We're looking for more self-contained features that can be handled in a 10-week commitment!

[terriko]

From @anthonyharrison

• doing something appropriate if we find something and don't have a checker.
• improved information on how to fix -- already have the available fix tool, but might be able to get information from the cve links as well.

[terriko]

Came up in a private conversation: Date-based vulnerability information. Right now, we basically don't do anything but print information if a checker gives a version as UNKNOWN. But in theory, we could combine the timestamp on the file, the vendor/product that we partially found, and then list out vulnerabilities that have been found since that time in that product.

Note that while CVEs have date information attached, I don't think we currently store that, so it would require a database change. I'm not sure how useful it would be in practice, but for folk scanning older software where our signatures aren't as good, this could potentially generate some interesting results if we had it as an option recommended when an UNKNOWN is found?

[terriko]

more brainstorming:

• improving windows support (e.g. handling DLLs)
• adding macos support (now supported by Github Actions so we could have CI for this)
• report improvements? full reports (including all descriptions),
• HTML report improvements: updating js libraries, improving tests
• mapping which applications include code that needs to be rebuilt.
• triage enhancements?

[ashok-arora]

• adding macos support (now supported by Github Actions so we could have CI for this)

I would love to work on adding macOS support. Could you expand a bit more on the work required for it?

[terriko]

I can't really because I haven't investigated it (taht's why this is in a brainstorming file and not a complete idea) but here's some guesses:

• Checking to make sure that utilities like 'file' behave the same as they do on linux. MacOS is BSD-based so the utilities are pretty similar but often have slightly different flags/output
• Finding appropriate replacements for anything not typically installed by default (e.g. is there a cabextract equivalent? what's the preferred zip extraction libraries?)
• Testing testing testing. Adding additional tests for any codepath that's different on macos (e.g. because a flag is different)
• Setting up tests in CI (GitHub Actions) for supported versions of Python
• updating docs with setup instructions and information for macos users
• potentially adding code for dealing with typical macos packages (they're... sort of directories but sort of not if I remember correctly)

Basically, pip install cve-bin-tool and see what breaks, then put together a proposal to fix anything you find, I guess? I don't have a modern macos machine handy at the moment but last time I tried it basically just worked, so there may not be enough to make a 175hr project here. I don't actually know.