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

[Ilari Liusvaara <ilari.liusvaara@elisanet.fi>]

On Wed, Jan 13, 2010 at 02:11:14PM -0500, Avery Pennarun wrote:
> 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