3 ms·
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, henc
by 4gotunameagain 3y ago
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.
- kragen 3y agoi'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
- 4gotunameagain 3y agoI 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
- kragen 3y agothere's no such thing as a 'git instance'
- 4gotunameagain 3y agohaha 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.
- kragen 3y agoin 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