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

From: Andreas Krey <a.krey@gmx.de>
Date: Jan 13, 2010, 16:17 UTC
Message-ID: <20100113161711.GB17687@inner.home.ulmdo.de>
In-Reply-To: <20100113144745.GA7246@Knoppix>

On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote: ...

Show 6 quoted lines

> > It doesn't need to, really. stunnel sets the environment variable
> > SSL_CLIENT_DN with the distinguished name of the client certificate,
> > which can be used in the hook scripts ('update') on the server.
> 
> That would be useless. Data about authenticated client needs to fed to
> authorization decisions already before invoking git.

If you don't want public read access then you need to wedge a script between stunnel and git itself that checks whether authentication is present, yes.

> And besides: Gits:// uses certificates as keypairs,

My gripe with this is that I would expect gits: to be the same as git: except that there is SSL underneath. git: does not have authentication, so there should be none in gits: except what SSL provides. (And the auth via unix domain sockets would be usable for plain git: as well; there is no reason to encrypt local traffic?)

(Is the unix auth via unix domain sockets part of GnuTLS?)

> which would make DN
> data absolutely useless because it is untrustworthy. And adding PKI
> is way too complicated.

That's another story. I think that it would be possible nowadays to implement gits:// (in both ways) via core.gitproxy and a server-side wrapper program (stunnel or else), but that has the disadvantage of being unable to just provide a clone url without installing special software besides git.

...

> The authentication support for smart-http seems pretty bad (making the
> old mistake of not binding authentications).

Mind to explain 'binding authentications'?

Andreas