[PATCH] RFC: proxy-command support for git://

I spend some of my time using a network that only allows outgoing TCP
connections to certain ports, and the git-daemon port is not one of them.
This patch below implements an analogue to ssh's ProxyCommand feature
for git, as a less messy alternative to ssh port forwarding.  One can
use it to ssh to a bastion host and netcat to the destination:

  $ cat ~/bin/my-git-proxy-command
  #!/bin/sh
  exec ssh bastionhost nc "$1" "$2"

I've done a few pulls and a clone with it, and it seems to work.


Questions:

* Can git already do this and I just failed to notice?

* Where should git_use_proxy() look?  Some git configuration file?
  An environment variable?  Both?  Somewhere else?

It also needs to support non-default ports and probably other things I missed.

diff --git a/connect.c b/connect.c
index c2badc7..646e26f 100644
--- a/connect.c
+++ b/connect.c

@@ -448,6 +448,40 @@ static int git_tcp_connect(int fd[2], co
 
 #endif /* NO_IPV6 */
 
+static int git_proxy_connect(int fd[2], const char *prog, char *host, char *path)
+{
+	char *command = "my-git-proxy-command"; /* FIXME: cf. git_use_proxy() */
+	char *port = STR(DEFAULT_GIT_PORT);
+	int pipefd[2][2];
+	pid_t pid;
+
+	if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
+		die("unable to create pipe pair for communication");
+	pid = fork();
+	if (!pid) {
+		dup2(pipefd[1][0], 0);
+		dup2(pipefd[0][1], 1);
+		close(pipefd[0][0]);
+		close(pipefd[0][1]);
+		close(pipefd[1][0]);
+		close(pipefd[1][1]);
+		execlp(command, command, host, port, NULL);
+		die("exec failed");
+	}
+	fd[0] = pipefd[0][0];
+	fd[1] = pipefd[1][1];
+	close(pipefd[0][1]);
+	close(pipefd[1][0]);
+	packet_write(fd[1], "%s %s\n", prog, path);
+	return pid;
+}
+
+static int git_use_proxy(void)
+{
+	/* FIXME: look for the proxy command somewhere - repo's config? environment? */
+	return 1;
+}
+
 /*
  * Yeah, yeah, fixme. Need to pass in the heads etc.
  */

@@ -482,8 +516,11 @@ int git_connect(int fd[2], char *url, co
 		}
 	}
 
-	if (protocol == PROTO_GIT)
+	if (protocol == PROTO_GIT) {
+		if (git_use_proxy())
+			return git_proxy_connect(fd, prog, host, path);
 		return git_tcp_connect(fd, prog, host, path);
+	}
 
 	if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
 		die("unable to create pipe pair for communication");

-- 
Dag vijandelijk luchtschip de huismeester is dood

Paul Collins [off-list ref] writes:

I spend some of my time using a network that only allows outgoing TCP
connections to certain ports, and the git-daemon port is not one of them.
This patch below implements an analogue to ssh's ProxyCommand feature
for git, as a less messy alternative to ssh port forwarding.

Wonderful.

Questions:

* Can git already do this and I just failed to notice?

Maybe I just failed to notice this too, but I do not think so.

* Where should git_use_proxy() look?  Some git configuration file?
  An environment variable?  Both?  Somewhere else?

My preference is put something in .git/config to describe which
proxy command (maybe the same one with different argument) to
use depending on where you are going.  When you have internal
hosts and external hosts you would want this to apply only to
external hosts.  Maybe you have two or more gateways and
depending on which external host you are going you may want to
use different proxied connection.  On top of the config file,
making it overridable from an environment variable would be
sensible.

On Thu, 3 Nov 2005, Junio C Hamano wrote:

Paul Collins [off-list ref] writes:

quoted

I spend some of my time using a network that only allows outgoing TCP
connections to certain ports, and the git-daemon port is not one of them.
This patch below implements an analogue to ssh's ProxyCommand feature
for git, as a less messy alternative to ssh port forwarding.

Wonderful.

quoted

Questions:

* Can git already do this and I just failed to notice?

Maybe I just failed to notice this too, but I do not think so.

Actually, you could. TWO ways, in fact, afaik.

Just use the "ssh://host/pathname" format (or just "host:pathname") and 
the GIT_SSH environment variable.

You could also override the local command-name with

	git-send-pack --exec=my-local-send-program /machine/repo/path

where the "my-local-send-program" will parse /machine/repo/path thing. At 
least that works with git-send-pack, but it's possible it doesn't work 
with some other logic (ie "git push" might decide that it's unhappy that 
/machine/repo/path doesn't exist locally because it thinks it's a local 
path).

		Linus

Another way to do this would be using the ~/.ssh/config file.  It would
look something like this:

Host host
  ProxyCommand ...

Or, more generically...

Host *.*
  ProxyCommand ...

Host *.* assumes that if the machine name has a '.' in it then you are
trying to get outside the firewall.  This might not be a good assumption
but it works well where I am.

Then use host:pathname or ssh://host/pathname or whatever.

The advantage of using this is that it works for anything that uses ssh
to get outside the firewall.  Not just git.  So, setup is minimal.

Carl

On Thu, Nov 03, 2005 at 11:22:35AM -0800, Linus Torvalds wrote:

On Thu, 3 Nov 2005, Junio C Hamano wrote:

quoted

Paul Collins [off-list ref] writes:

quoted

I spend some of my time using a network that only allows outgoing TCP
connections to certain ports, and the git-daemon port is not one of them.
This patch below implements an analogue to ssh's ProxyCommand feature
for git, as a less messy alternative to ssh port forwarding.

Wonderful.

quoted

Questions:

* Can git already do this and I just failed to notice?

Maybe I just failed to notice this too, but I do not think so.

Actually, you could. TWO ways, in fact, afaik.

Just use the "ssh://host/pathname" format (or just "host:pathname") and 
the GIT_SSH environment variable.

You could also override the local command-name with

	git-send-pack --exec=my-local-send-program /machine/repo/path

where the "my-local-send-program" will parse /machine/repo/path thing. At 
least that works with git-send-pack, but it's possible it doesn't work 
with some other logic (ie "git push" might decide that it's unhappy that 
/machine/repo/path doesn't exist locally because it thinks it's a local 
path).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Carl Baldwin                        Systems VLSI Laboratory
 Hewlett Packard Company
 MS 88                               work: 970 898-1523
 3404 E. Harmony Rd.                 work: Carl.N.Baldwin@hp.com
 Fort Collins, CO 80525              home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -