Re: [RFC 0/2] Git-over-TLS (gits://) client side support

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Jan 13, 2010, 20:00 UTC
Message-ID: <20100113200027.GA8207@Knoppix>
In-Reply-To: <32541b131001131111u6bb0de01qe6cc1ecde5119084@mail.gmail.com>

On Wed, Jan 13, 2010 at 02:11:14PM -0500, Avery Pennarun wrote:

Show 11 quoted lines

> On Wed, Jan 13, 2010 at 8:57 AM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> It sounds to me like you're doing two different things with this patch series:
> 
> 1) Adding additional authorization features (assuming the user is
> already authenticated) to git-daemon
>
> 2) Creating a TLS encryption layer with authentication support.
>
> #1 sounds like it could be its own patch series even if you don't have
> #2, and could be reviewed separately.

This series (really only one patch, only split because its large) only contains client parts, not server ones (not seperately or via patching git-daemon).

And besides the daemon for gits:// was written from libraries up.

> #2 sounds like it is not even git-specific.  You've decided that ssh
> and stunnel don't fit your needs; what makes your solution not a
> general TLS-based authentication layer, like stunnel but with
> different certificate management?

Stunnel seems mainly "tunnel stuff using SSL/TLS" type thing and any support for auth in it seems afterthought. At least that's what I got from reading the manuals for it.

> If it's really a general layer,
> maybe it should be distributed separately and git could be taught how
> to use it *or* stunnel (or ssh, as it does now) for its transport
> encryption/authentication.

The way serverside works is quite different from git-daemon. On client side there are also some virtually inavoidable bidirectional couplings (breaks layering) between generic and git-specific parts.

Yes, the code is split into two layers, but both layers contain git- specific details. And the lower layer is low-level transport control code, that doesn't even know how to configure TLS connection (that is quite high-level task).

And ssh:// is not git:// tunneled over SSH, the request passing is done differently.

-Ilari