4 ms·
Repo access doens't stop people from injecting code into your repository. A pull request actually puts objects into your repo, but under a different ref than he
by mixologic 10y ago
Repo access doens't stop people from injecting code into your repository. A pull request actually puts objects into your repo, but under a different ref than heads and tags.
1. Go to github, do a git clone 'repo' --mirror
2. cd to the bare repo.git and do a git show-ref and you will see all the pull requests in that repo. If any of those pull requests contained a duplicate hash, then in theory they would be colliding with your existing objects. But since git falls back to whatever was there first, I think it would be very challenging indeed to subvert a repo. You'd essentially have to find somebody who's forked a repo with the intention of submitting a PR, say, on a long running feature branch.
You could then submit your PR based off hashes in their repo before they do, which would probably mean your colliding object would get preference.
Its pretty far fetched, but the vector is non-zero.
- E6300 10y agoIt's easier than that. Someone could create a benign patch and a malicious patch that collides the hash. But what could they do with that? For example, let's say it goes (letter##number represents the hashes): State 1: Real repo: R3 -> R2 -> R1 -> R0 (note: R3 is the head) Benign PR: B1 -> B0 -> R1 Malicious PR: M1 -> M0 -> R1 (note: M0 = B0, but the contents are different) State 2, after merging Benign PR: Real repo: R4 -> R3 -> R2 -> R1 -> R0, R4 -> B1 -> B0 -> R1 If Malicious PR was merged now, Git would, I imagine, just believe that M1 is a commit that branched off of B0, since that's where the "pointer" is at. So, yeah, what would this actually accomplish?