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 -- 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