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

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

On Wed, 13 Jan 2010 19:36:10 +0000, Ilari Liusvaara wrote:
...
> That would violate layering badly. You need to decode the request
> first before you can authorize. And the git daemon does that.

Well, yes. The script hackery would just decide between 'is allowed
to read (or write commits)' and 'is allowed to modify refs'. On the
other hand, git-daemon does not do fine-grained (read: per-branch)
access control, you'd only prevent pushing commits at all.

...
> > (Is the unix auth via unix domain sockets part of GnuTLS?)
> 
> No, that server-only feature is part of the OS itself. In fact, it
> needs no client-side support.

Ok, then I'll be really interested in the server-side support and
the man pages on the whole stuff. Especially in how this is going
to be different from what ssh:// does or can do.

...
> GIT_PROXY abuse? There are even better ways: smart transport remote
> helpers (in next I think). Git can actually dispatch those (and yes,
> that's exactly what this uses).

Yeah, since the last mail I noticed that gitproxy is not quite what
some google hits suggest, and should have read the patch in some
more detail to find that gits is a remote helper.

Please consider my objections revoked, other than the claim that
it could be done with stunnel, however ugly that would be.

...
> Actually, that was little badly choosen term and not the true problem,
> but the basic problem is that one peer has to trust the the other peer's
> authentication for security of its own authentication.

I don't see how that would endanger the standard certificate auth in ssl
(client or server).

...
> HTTP basic auth can be trivially sniffed if attacker can become other end
> of the encrypted link

Of course, you have another problem in that case...also I'd personally
like to rely on ssl client certificates when using https.

Andreas