From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: Jeff King <peff@peff.net>,
jnareb@gmail.com, Nicolas Pitre <nico@cam.org>,
"Shawn O. Pearce" <spearce@spearce.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: git-daemon on NSLU2
Date: Sun, 26 Aug 2007 11:26:07 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0708261118260.25853@woody.linux-foundation.org> (raw)
In-Reply-To: <9e4733910708261106u3fecde67m8045ddba3aa57650@mail.gmail.com>
On Sun, 26 Aug 2007, Jon Smirl wrote:
>
> On 8/26/07, Linus Torvalds <torvalds@linux-foundation.org> 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
next prev parent reply other threads:[~2007-08-26 18:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-24 5:54 git-daemon on NSLU2 Jon Smirl
2007-08-24 6:21 ` Shawn O. Pearce
2007-08-24 19:38 ` Jon Smirl
2007-08-24 20:23 ` Nicolas Pitre
2007-08-24 21:17 ` Jon Smirl
2007-08-24 21:54 ` Nicolas Pitre
2007-08-24 22:06 ` Jon Smirl
2007-08-24 22:39 ` Jakub Narebski
2007-08-24 22:59 ` Junio C Hamano
2007-08-24 23:21 ` Jakub Narebski
2007-08-24 23:46 ` Jon Smirl
2007-08-25 0:04 ` Junio C Hamano
2007-08-25 7:12 ` David Kastrup
2007-08-25 17:02 ` Salikh Zakirov
2007-08-25 0:10 ` Nicolas Pitre
2007-08-24 23:28 ` Linus Torvalds
2007-08-25 15:44 ` Jon Smirl
2007-08-26 9:33 ` Jeff King
2007-08-26 16:34 ` Jon Smirl
2007-08-26 17:15 ` Linus Torvalds
2007-08-26 18:06 ` Jon Smirl
2007-08-26 18:26 ` Linus Torvalds [this message]
2007-08-26 19:00 ` Jon Smirl
2007-08-26 20:19 ` Linus Torvalds
2007-08-26 21:22 ` Junio C Hamano
2007-08-27 11:03 ` Theodore Tso
2007-08-27 16:26 ` Linus Torvalds
2007-08-26 22:24 ` Daniel Hulme
2007-08-27 0:14 ` Jakub Narebski
2007-08-24 20:27 ` Jon Smirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.0.999.0708261118260.25853@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=jonsmirl@gmail.com \
--cc=nico@cam.org \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).