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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jan 13, 2010, 19:11 UTC
Message-ID: <32541b131001131111u6bb0de01qe6cc1ecde5119084@mail.gmail.com>
In-Reply-To: <20100113135753.GA7095@Knoppix>

On Wed, Jan 13, 2010 at 8:57 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

Show 15 quoted lines

> On Wed, Jan 13, 2010 at 08:39:12PM +0700, Nguyen Thai Ngoc Duy wrote:
>>
>> Can we rely on an external program, like stunnel, to do the job instead?
>
> No. The way authentication is done is very unusual. I don't think stunnel (or
> anything else) can deal with such modes. And the reason authentications are
> done like they are done in order to minimize points of failure (getting
> really annoyed at failure modes sshd introduced was one big reason for
> writing this).
>
> I _definitely_ do not want to mess with X.509. And its not just about me
> messing with it, it is also about pushing it to users.
>
> And one would need custom daemon anyway even if one used stunnel.
> git-daemon just can't deal with authentication data.

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.

#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? 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.

Have fun,

Avery