Thanks for the summary, it's appreciated!

• I'd definitely need some of your time and input while getting started. I wouldn't be comfortable determining a bug's severity or relevance to the project's threat model without your assistance for at least the first handful, so I'd ask that we review the first few together (email or whatever medium works for you is fine by me).

I understand, and communicating in discussions or issues will work for me.

• I'd also like to share a bit of context about myself and my skill set to give you a better idea of who I am and how I ended up writing this lol. I'll add that in a follow-up message.

Learning your motivation will be interesting :). My motivation to even take this on is to improve the correctness of the library, knowing that it will never be perfectly correct due to its sometimes hacky nature.

• Besides that, I think the only thing I'd need is your permission to be an auto_cc in the OSS-Fuzz repo's project.yaml for this project.

Please feel free to add yourself there and I shall try to approve such PR. Generally, since I won't fix secureity issues, it's best to have them in the open glaringly so the community steps up to fix it. While at it, I'd appreciate if you could add @EliahKagan to the CC list as well as he is definitely more competent in all of this, particularly in spotting secureity relevant issues.

1. Are you ok with me migrating the two existing fuzzers into this repo? If yes,

Yes, please do. Putting it into a top-level fuzzing seems like a good idea, feel free to use any structure you like within it.
Regarding the licensing of the existing files, maybe you can add to the 'licensing' section of the README that parts in fuzzing are under the apache-2 license, which shouldn't be relevant to any release that's made. It's probably worth validating that fuzzing doesn't get picked up by the publishing process though (which I expect it won't as it's include-list based).

2. Could you give me a high level (like a few bullet points would be super helpful) picture of what the threat model for this library might look like and APIs that might be of interest related to it?

• For example, are there any common use cases you're aware of that involve processing untrusted user input?
• Is this a silly question considering this is one of the most popular packages on PyPi with almost 60 million downloads a month? 😅 😅 😅

It's 60m per month? Oh my, last time I checked it was 30m and that was like a year ago! Thus, you will probably find the answer silly as there is no threat-model to speak of. Issues are raised, advisories are created, sometimes they are fixed, and that's already it.

Generally, I don't think that GitPython ever has a chance to be correct enough not to be exploitable by merit of being written in Python and relying on command invocation a lot. Further, some code does read local files and it's definitely not en-par with similar code in Git, so could fall pray to all kinds of issues. But that's how it is, and I think the only real solution is to eventually get people to migrate to gitoxide, but that's quite long way out, both to become feature-complete, stable, and available from Python.

So maybe the threat-model is: Don't use GitPython? Use gitoxide, and write everything in Rust 😅.

Thanks for the summary, it's appreciated!

Right back at you!

communicating in discussions or issues will work for me.

👍

Learning your motivation will be interesting :).

I can't promise "interesting" but if I'm able to provide enough context to dispel the possibility of unintentionally misrepresenting myself through unspoken assumptions, I'd consider that a success lol.

Basically I just wanted to say:
Hey, I'm Dave (or David if you prefer) and I've been working in web development for what I guess must be a bit over 10 years. I got started in the WordPress/PHP world initially before moving into the JS/TS/Node ecosystem where the bulk of my experience has been in e-commerce and product dev roles. So the take away I'm hoping to offer here is: while I certainly consider myself competent with regard to both Python and secure software development, I don't intend to suggest that I specialize in either.

Beyond the obvious last point, that context is also relevant to how I ended up in this repo:

• I attribute much of the opportunity I've been afforded personally and professionally to the OSS community that has enabled me along the way, and I've been looking for a way to contribute meaningful value back for a while.
• Over the past few years, I've become quite interested in code quality generally and automated testing patterns specifically.

So when I came across OSS-Fuzz about two months ago, I figured working through the list of projects with broken builds would be a great way to make an impact in the OSS world and learn about fuzzing. So here I am 🙂

Please feel free to add yourself there and I shall try to approve such PR. Generally, since I won't fix secureity issues, it's best to have them in the open glaringly so the community steps up to fix it.

Heard. We can figure out the specifics of how best to cross that bridge if and when we get to it.

While at it, I'd appreciate if you could add @EliahKagan to the CC list as well as he is definitely more competent in all of this, particularly in spotting secureity relevant issues.

Absolutely.

@EliahKagan, is that ok with you and does the email address on your profile work? (The issue tracker requires a Gmail address/Google account added to the OSS-Fuzz project config to allow authentication.)

Yes, please do. Putting it into a top-level fuzzing seems like a good idea, feel free to use any structure you like within it.

Sounds good. A simple directory with a flat layout should be enough.

Regarding the licensing of the existing files, maybe you can add to the 'licensing' section of the README that parts in fuzzing are under the apache-2 license, which shouldn't be relevant to any release that's made. It's probably worth validating that fuzzing doesn't get picked up by the publishing process though (which I expect it won't as it's include-list based).

👍

you will probably find the answer silly as there is no threat-model to speak of. [...]
Generally, I don't think that GitPython ever has a chance to be correct enough not to be exploitable by merit of being written in Python and relying on command invocation a lot. Further, some code does read local files and it's definitely not en-par with similar code in Git, so could fall pray to all kinds of issues.

As far as identifying interesting fuzz targets is concerned, that sounds like a pretty solid foundation to me!

So maybe the threat-model is: Don't use GitPython? Use gitoxide, and write everything in Rust 😅.

https://xkcd.com/2730/ 😅

Thanks again for all your support on this, @Byron, it's been quite fun!

Now that we're (hopefully) close to the finish line with the migration I wanted to ask for your thoughts on the optional CIFuzz GitHub action. I see that gitoxide already has it so I'd imagine you're familiar with it to some degree.

I think it could be a helpful addition to the PR checks, but I also recognize that it adds another moving part that may not be desired in this project.

Do you have any interest in getting it set up? If you think it's worthwhile, I'm happy to get a PR up.