On Wed, Jan 13, 2010 at 05:17:11PM +0100, Andreas Krey wrote: > On Wed, 13 Jan 2010 16:47:47 +0000, Ilari Liusvaara wrote: > > 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. That would violate layering badly. You need to decode the request first before you can authorize. And the git daemon does that. > > 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. All authentication in gits:// is at TLS (SSL) level or even lower. > (And the auth via unix domain sockets would be > usable for plain git: as well; there is no reason to encrypt > local traffic?) In fact, git-remote-gits has unencrypted mode (should be compatible with git-daemon). The reason its there is mainly for Unix domain sockets support and more advanced IPv6 support (interface indexes and numeric addresses actually work). > (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. > 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. 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). And gits:// client is also buildable selfstanding. That would require new client software, but its still nicer than GIT_PROXY abuse. Another problem with GIT_PROXY abuse: How to deal with potentially multiple custom protocols. Remote helpers can deal with that nicely. > ... > > The authentication support for smart-http seems pretty bad (making the > > old mistake of not binding authentications). > > Mind to explain 'binding authentications'? 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. In how authentications used by gits:// are designed, even if client doesn't detect trying to authenticate with attacker, the attacker doesn't get any replayable credentials without breaking crypto keys (as opposed to just passwords). This holds true even for password authentication (PAKE-type scheme is used). HTTP basic auth can be trivially sniffed if attacker can become other end of the encrypted link (crypto is by far the strongest link...). Digest auth is harder, but its essentially brute force against password (as opposed to trying to break a key). -Ilari -- 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