On Tue, May 17, 2011 at 7:19 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > On Mon, May 16, 2011 at 18:32, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote: >> PS: Gitolite does have unreleased code to do this but it's a hack with >> several limitations. ÂGitolite makes a temp "clone -l", deletes all >> refs from it that the user has no access to, then redirects the >> git-upload-pack to that repo instead ;-) > > Cute hack. Doesn't prevent the evil client from making an indirect > reference to something you shouldn't have. :-) You mean he constructs a commit that references a SHA he should not be having, pushes that to the branch he is allowed to read/write, then pulls it down again to now really get that commit? Yeah, I started writing a hook that looks at `rev-list oldsha..newsha`, and for each commit run `git branch --contains SHA` and make sure it either (a) is totally new to the repo, ie no ref contains this commit or (b) at least one of the refs that contains this commit is allowed for this user. I haven't had time to do that though. Also, if there has been a rewind/force-push and the attacker knows the now unreachable SHA, this would not catch it (it'd look like a totally new commit). That's a hard one. Having two repos is still the best plan ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html