On Wed, Jan 13, 2010 at 8:57 AM, Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html