On Tue, Mar 3, 2009 at 3:23 AM, Jeff King <peff@xxxxxxxx> wrote: > > What about the client just calling init-serve on the server as a program > which does whatever it wants to create a repo? The shipped default would > be: > > #!/bin/sh > echo >&2 Sorry, repo creation not allowed. > exit 1 > > Sites who want to give their users full creation access would do (and > obviously the --mkdir option would need to be added): > > #!/bin/sh > exec git init --mkdir "$@" > > Sites which want to restrict can do: > > #!/bin/sh > for i in "$@"; do > case "$i" in > --bare) ;; > *) echo >&2 Forbidden argument: $i; exit 1 ;; > esac > done > exec git init --mkdir "$@" > > Sites like GitHub or Gerrit can munge the arguments as appropriate. They > could even allow site-specific options if they wanted as long as they > were syntactically correct (i.e., "git init --gerrit-base=foo remote" > would pass the argument through to the remote unharmed). FWIW, I like this proposal. The only issue I have which I think simply cannot be reconciled is this: it doesn't do anything to help a user that expects "git push --init ssh://..." to "just work". (And here I'm assuming push --init just calls init --remote under the covers.) The reason is that such a user is probably just using the git supplied by their vendor, and thus remote creation is likely disabled by default. The best I can come up with is a different error message: "Sorry, remote repo creation not allowed. To enable it, blah blah blah" So at least the user has a clue that git can help them here, but there are security reasons it does not do so by default. j. -- 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
