Re: What's up with the GIT archive on www.kernel.org?

    Linus> You can try removing all the packs in your
    Linus> .git/objects/packs directory. Everything _should_ still
    Linus> work fine.

Does "everything" include someone doing

    git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/whatever.git

How about http:// instead of rsync://?

In other words, is the git network transport smart enough to handle
the alternates path?

Or is the idea that everyone will clone your tree and then pull extra
stuff from other trees?

 - R.

On Sun, 11 Sep 2005, Roland Dreier wrote:

Does "everything" include someone doing

    git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/whatever.git

Nope. Only server-side smart protocols will handle this.

There is such an anonymous server, btw: "git-daemon" implements anonymous 
access much more efficient than rsync/http. Sadly, kernel.org still 
doesn't offer it (but it's now used in the wild, ie I've done a couple of 
merges with people running the git daemon).

In other words, is the git network transport smart enough to handle
the alternates path?

The _git_ network transport is. rsync and http aren't.

		Linus

On Sun, 11 Sep 2005, Linus Torvalds wrote:

The _git_ network transport is. rsync and http aren't.

Btw, there's no reason why a client-side thing couldn't just parse the 
"alternates" thing, and if it doesn't find the objects in the main object 
directory, go and fetch them from the alternates itself.

IOW, this is not a fundamental problem with alternates, it's just that
since there is no server-side smarts to handle it (ie just raw file access
with rsync/http), it needs to be handled at the client side instead.

		Linus

On 9/11/05, Linus Torvalds [off-list ref] wrote:

There is such an anonymous server, btw: "git-daemon" implements anonymous
access much more efficient than rsync/http. Sadly, kernel.org still
doesn't offer it (but it's now used in the wild, ie I've done a couple of
merges with people running the git daemon).

Should the git daemon take a look at objects/info/alternates to check
that if it exists, it
points to a repository that also has a "git-daemon-export-ok" file?  
I don't see that this
could be used for anything nasty, but it does provide a loophole where
the daemon may
open files outside the initial repository ... so a sanity check seems in order.

-Tony

On Mon, 12 Sep 2005, Tony Luck wrote:

Should the git daemon take a look at objects/info/alternates to check
that if it exists, it points to a repository that also has a
"git-daemon-export-ok" file?

I considered it, but decided against the complexity. I just don't see the 
point. The "git-daemon-export-ok" is not so much about security as about 
_accidental_ exposure. 

Remember: the security is in the writing. If you allow "bad people" enough
capabilities that they can create their own git archive and can read the
target archive, those "bad people" could just export the target archive
some other way in the first place (ie they could have just copied the
files over to their own area).

And there are actually real downsides to requiring "git-daemon-export-ok" 
from a security standpoint. In particular, imagine that a company has a 
"master archive", and wants to export just a particular "public branch" 
from that master archive. The way you can do that right now is to create a 
dummy git archive, that is empty except for having one head (symlink to 
the public branch head in the master) and an "alternates" pointer to the 
master.

See? You don't actually want to expose the master archive itself: so 
requiring that one to also have "git-daemon-export-ok" would actually 
_defeat_ the security in the system. 

So the git approach to security is that you secure the writing side.  
That's where you use ssh. And even if you happen to run git-daemon, it
will never export anything that you didn't explicitly mark for export, so
it defaults to a "nothing exported" mode. But once you mark a project for
public export, the branches exposed there really are public.

(And the branches _not_ exposed there are private. Sure, if you can guess
the SHA1 ID's, you can make git-daemon export them, but the point is that
git-daemon will never expose any SHA1's from other projects unless they
have the "git-daemon-export-ok" flag set. And the thing is, if you know
the SHA1's, you already know the contents and you had a leak some other
way, so..).

			Linus