From: Avery Pennarun <apenwarr@gmail.com>
Date: Wed, 13 Jan 2010 19:11:14 GMT
Subject: Re: [RFC 0/2] Git-over-TLS (gits://) client side support
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:
> 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