Re: [RFC][PATCH] Allow transfer of any valid sha1

[ebiederm@xmission.com (Eric W. Biederman)]

Linus Torvalds <torvalds@osdl.org> 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