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

[Andreas Krey <a.krey@gmx.de>]

On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote:
...
> > 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