Linus Torvalds <torvalds@xxxxxxxx> writes: > On Thu, 25 May 2006, Eric W. Biederman wrote: >> >> My basic argument is that starting a pull with a commit that is not a >> reference is no worse than staring a pull from a broken repository. The >> same checks that protects us should work in either case. > > I think Junio reacted to the subject line, which was somewhat badly > phrased. You're not looking to transfer random objects, you're looking to > _start_ a branch at any arbitrary known point. Probably, but if I understood enough to get the subject line right the first time I probably would have understood enough to just send a patch :) > However, Junio's point is probably that the "any valid SHA1" might > actually point to a broken tree, even if it exists on the server. > > Of course, in that case hopefully git-rev-list exits with an error, and > the server doesn't generate any pack at all rather than generating a > broken one. > > However, there's a (questionable) security issue: what if the server > doesn't _want_ to expose certain branches? Arguably, if you know the top > SHA1, you likely know all that it contains, but it may be a valid argument > to say that if the SHA1 isn't an exported branch, you shouldn't > necessarily be able to follow it. Agreed and I mentioned this one earlier. However the only way the above scenario can even happen in a useful manner is with a shared object store for several repositories. Otherwise you couldn't access the data you don't want to share. I can't think of a valid argument against not sharing an entire repository except David Woodhouse's bandwidth concern. Of course what was wanted there was a test a limit to how far back in the history you could look for a common commit, which is something different. In general it is much easier to guarantee that either a repository is shared or it is not. Making a guarantee that objects that "git-fsck-objects --unreachable --full" identifies will never be downloaded is difficult, and probably not worth encouraging people to do. That said it is easy to keep the current behavior as an option, so the security policy issue shouldn't limit the technical discussion. Eric - : 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