On Sun, 26 Aug 2007, Jon Smirl wrote: > > On 8/26/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > And there's actually a deeper problem: the current native protocol > > guarantees that the objects sent over are only those that are reachable. > > That matters. It matters for subtle security issues (maybe you are > > exporting some repository that was rebased, and has objects that you > > didn't *intend* to make public!), but it also matters for issues like git > > "alternates" files. > > Are these objects visible through the other protocols? It seems > dangerous to leave something on an open server that you want to keep > hidden. They'd be visible to any stupid walker, yes. But if you're security-conscious, you'd simply not *allow* any stupid walkers. One of the goals of "git-daemon" was to have a simple service that was "obviously secure". Now, it's debatable just how obvious the daemon is, but it really is pretty simple, and I do think it should be possible to almost statically validate that it only ever reads files, and that it will only ever read files that act like valid *git* data. Some people may care about that kind of thing. I don't know how many, but it really was one of the design criteria (which is why, for example, git daemon will just silently close the connection if it finds something fishy: no fishing expeditions with bad clients trying to figure out what files exist on a server allowed!). So the fact that a web server or rsync will expose everything is kind of irrelevant - those are *designed* to expose everything. git-daemon was designed *not* to do that. > Doesn't kernel.org use alternates or something equivalent for serving > up all those nearly identical kernel trees? Absolutely. And that's the point. "git-daemon" will serve a nice individualized pack, even though any particular repository doesn't have one, but is really a combination of "the base Linus pack + extensions". > > So it's not actually clear how the initial clone thing can be optimized on > > the server side. > > > > It's easier to optimize on the *client* side: just do the initial clone > > with rsync/http (and "git gc" it on the client afterwards), and then > > change it to the git native protocol after the clone. > > Even better, get them to clone from kernel.org and then just fetch in > the differences from my server. It's an educational problem. Yes. > How about changing initial clone to refuse to use the git protocol? Absolutely not. It's quite often the best one to use (the ssh protocol has the exact same issues, and is the only secure protocol). But on a SNLU2, maybe *you* want to make your server side refuse it? I would be easy enough: if the client doesn't report any existing SHA1's, you just say "I'm not going to work with you". Linus - 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
