On Tue, Dec 01, 2009 at 11:30:09AM -0800, Shawn O. Pearce wrote: > Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> wrote: > > > > For instance, to support new types of authentication for smart transports > > without patching client git binaries (SSH has lots of failure modes that > > are quite nasty to debug) or abusing GIT_PROXY (yuck). > > So the bulk of this series is about making a proxy for git:// > easier to tie into git? This is making the "layer 5/6" parts of git:// easier to replace, for whatever reason that replacement may be desired (and the lower layer is just assumed to be some kind of full-duplex link). The part about abusing GIT_PROXY is _very_ nasty hack to be able to layer 6 gateway git smart transports. The git:// protocol stack is: - Git smart transport subprotocols (upload-pack, upload-archive and receive-pack) - git:// (request signaling and data passing) - TCP/IP (or comparable) And ssh://: - Git smart transport subprotocols (upload-pack, upload-archive and receive-pack) - SSH (request signaling, data passing, encrypt & auth). - TCP/IP (or comparable) Smart-HTTP: - RPC versions of git smart transport subprotocols - HTTP - TLS (optional) - TCP/IP (or comparable) This is about: - Git smart transport subprotocols (upload-pack, upload-archive and receive-pack) - Some prtocol layer(s) (request signaling, data passing, maybe encrypt & auth, etc...) - TCP/IP (or comparable) > Forgive me if I sound stupid, but for gits:// shouldn't that just > be a matter of git_connect() forking a git-remote-gits process > linked against openssl? Or, maybe it just runs `openssl s_client`? gits:// was just an example. There can be other interesting stuff (I don't even pretend my imagination is the limit). And I would rather link the gits:// handler to GnuTLS than OpenSSL, but that's seperate matter... As for "other interesting stuff": Smart transport using Kerberos auth (just throwing ideas, probably not going to implement that)? > Why go through all of this effort of making a really generic proxy > protocol system when the long-term plan is to just ship native > gits:// support as part of git-core? gits:// is not actual goal of this series. Its just something to build on top of it. -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