the git codebase is roughly 100× smaller than chromium, so, all else being equal, you'd expect 600× more bugs of any kind in chromium — more bugs per day in chromium than bugs per year in git

there are design considerations to consider, but it's not clear to me which way they shift the balance: chromium's sandboxing layer means that you need a sandbox escape, but, on the other hand, chromium intentionally downloads and executes malicious code all the time, and that's inherently riskier than what git does, which is efficiently synchronizing a merkle graph of blobs. it's hard to imagine that this matters more than the sheer size of the codebase, though

chromium's churn rate is also much higher, so the rate of new bug production is higher

Sure, but this does not take into account the appeal for trying to exploit said codebases. Who pulls from an untrusted git instance ? Very very few people, hence the very low incentive to look for exploits. Who uses Chromium ? E-ve-ry-one.

i'm pretty sure people clone git repos from unknown github users all the time. i can't be the only one. and there's a special incentive to exploit those people: they're the ones who build the software that runs everywhere else, so if you can own their laptops, you own the world

regardless, the nonexistence of security holes is a much, much better protection than insufficient incentives to find the undoubtedly numerous security holes

I said git instance, not repo.

I would imagine that by directly manipulating the cloning process and not just the repository, a larger attack vector could be exploited.

But yes, I agree with the rest of your points

there's no such thing as a 'git instance'

haha sure. so when you git clone something, it arrives to you through divination, and there is no larger attack vector once you can meddle with the entire communication part and not just the blobs and refs.

in this case it arrives to you through apache, which gives git the contents of the files it requests, just like the filesystem does when you clone a repo off a usb pendrive. there's no git-specific code running on the server when you clone that url

there is, however, a faster 'smart http' git cloning protocol which apache can't participate in, and that is indeed a potential attack surface. i don't think any of the bugs i linked upthread were in that protocol though