GSoC 2025: Start here

[terriko]

CVE Binary Tool is hoping to participate in GSoC 2025 under the Python Software Foundation umbrella. We won't know if we've been accepted until the end of Feburary 2025. You can view the GSoC dates and deadlines on Google's page This issue will be updated with more info as we know it.

About CVE Binary Tool

The CVE Binary Tool is a free, open source tool to help you find known vulnerabilities in software, using data from the National Vulnerability Database (NVD) list of Common Vulnerabilities and Exposures (CVEs).

The tool has two main modes of operation:

1. A binary scanner which helps you determine which packages may have been included as part of a piece of software. There are over 360 checkers which focus on common, vulnerable open source components such as openssl, libpng, libxml2 and expat.
2. Tools for scanning known component lists in various formats, including .csv, several linux distribution package lists, and several Software Bill of Materials (SBOM) formats.

It is intended to be used as part of your continuous integration system to enable regular vulnerability scanning and give you early warning of known issues in your supply chain. We expect the SBOM use case to become a lot more popular as people who work with the US government start needing to provide SBOMs as a matter of course, starting in 2023.

Dates:

• We won't know for sure if we're in until Feb 27, 2025. We'll be listed as part of "Python Software Foundation"

Project ideas:

• None yet! We're meeting Jan 29 and will have some project ideas after we've discussed them at the public meeting.

Note that we're trying to give projects of a size that we think can be completed within the gsoc program, but if you're pretty skilled you may be able to finish these and have extra time: make sure to include some "stretch goals" of things you'd like to work on if you finish early.

Related:

• The upcoming features brainstorming thread: discussion: Planning for 3.5 / 4.0 releases #4594

Not all ideas will be viable because of the constraints of the program and the software, but all ideas are welcome for discussion on the brainstorming thread even if we can't make them into gsoc projects.

We currently expect to have only enough mentors for 1-2 GSoC contributors in 2025. If you're interested in mentoring please contact @terriko or put a comment here!

Getting started:

• Getting started guide for GSoC contributors
  (cut and pasted below)

It can be really overwhelming figuring out how to start in a new project, so here's some steps we recommend:

Getting Started:

1. Follow the README and make sure you can run the tool. Try running it against random things on your hard drive and see if it finds anything. On a Linux system, your /bin directory usually yields some interesting results.
2. Run the tests. The CVE Binary tool has a number of unit tests. Make sure you know how to run them, and if you've never used pytest before, you might want to read up on it (we also have some tests still using python's unittest, but we're tending towrads pytest for new tests). Figure out how to run a single test!
3. Read the documentation. That should help you figure out what the tool is for and how people use it in more detail.
4. Read the new contributor guide

Some potential first contributions:

1. File issues. You might encounter a bug or something confusing in the documentation. Let us know if you do!
2. Update documentation. We especially appreciate documentation feedback from new users, since your "beginner mind" means you see things differently than experienced users, and will catch places where the documentation could be more detailed or improved.
3. Write a new test. Instructions for writing tests are here. This can be your first contribution!
4. Try fixing a bug. We have a few flagged as "good first issue". A number of those are new checkers, which although they might sound challenging are often pretty easy to write. Instructions on how to add a new checker are here.

We expect prospective GSoC students to have made at least one code contribution if they want their application to be considered, so now's a good time to get that going! You can ask for as much help as you need.

Got stuck?

1. Ask in the GSoC tagged issues! This "start here" issue is a good place for discussions.
2. We have a chat server on gitter. That allows for "live" chat but no one's actually sitting there 24/7 so you should expect to post your question and get an answer hours later when someone sees it.
3. Do not send private emails or direct messages with questions unless you're sharing a proposal draft that contains personal information

You should ask GSoC questions on public issues and in public channels. Why? First, we need contributors who are comfortable working in the open, and if you can't do that now there's a good chance you will not get accepted to GSoC. Second, a lot of the questions people have are the same, sometimes because we haven't done a great job of explaining things -- asking in public makes sure everyone has access to the answer even if they didn't know to ask it yet.

After your first contribution:

If you want to keep practicing once you've got a first commit under your belt, here's some other stuff you could try:

1. Try working on any other issue that we have filed.
2. Help triage issues: try to reproduce any bugs and put in a comment saying when and how you reproduced it or suggesting the bug be closed if it looks like it was already fixed.
3. Help review pull requests: if you see someone new who's struggling with fixing linter errors or failed tests, you can help out!
4. Help answer questions on issues. There's a lot of people asking "how do I get started on this?" right now -- if no one's answered, maybe see if you can?

Not so secret tips

We don't usually conduct interviews with our GSoC candidates, but we do take our interactions with you before GSoC into account when looking at your full application. Here's some things the mentors usually discuss after applications are in:

1. How well did this person handle code review or changes requested on their pull requests? Were they able to fix things? Did they generally remember for future pull requests?
2. How well does this person work in the open? Did they feel comfortable commenting on public issues or having discussions in gitter? (Sending us a lot of private messages gets you negative points here! Use the public channels whenever possible so more than one mentor can help you.)
3. How well did this person work with others? Did they help anyone out with code review or explanations?
4. How well did this person work once they got past their first commit? Were they able to take on more challenging issues? How much help did they need in breaking down problems before they could try them?
5. Do we think they'll be able to work independently with only a few hours of direct mentor feedback per week later in the coding period?
6. Are they going to be able to complete the project they proposed? How much help will they need to be successful?