On Fri, Oct 31, 2008 at 7:35 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Fri, 31 Oct 2008, Nicolas Pitre wrote: > >> On Sat, 1 Nov 2008, Johannes Schindelin wrote: >> >> > On Fri, 31 Oct 2008, Tom Preston-Werner wrote: >> > >> > > The current behavior of git-daemon is to simply close the connection >> > > on any error condition. This leaves the client without any >> > > information as to the cause of the failed fetch/push/etc. >> > > >> > > This patch allows get_remote_heads to accept a line prefixed with >> > > "ERR" that it can display to the user in an informative fashion. >> > > Once clients can understand this ERR line, git-daemon can be made to >> > > properly report "repository not found", "permission denied", or >> > > other errors. >> > > >> > > Example >> > > >> > > S: ERR No matching repository. >> > > C: fatal: remote error: No matching repository. >> > >> > Makes sense to me. >> >> Note that this behavior of not returning any reason for failure was >> argued to be a security feature in the past, by Linus I think. > > Yes. And it might still be considered one. You do not need to patch > git-daemon to use that facility (note that Tom's patch was only for the > client side). > > But for hosting sites such as repo.or.cz or GitHub, that security feature > just does not make sense, but it makes for support requests that could be > resolved better with a proper error message. We could also have the error messages sent back conditionally based on a command line switch. I've begun porting the changes I made in our Erlang git-daemon back to the C code, so maybe I'll give that a try. We *definitely* need good error messages for GitHub and I see no security risk in doing so. Maybe this is worth asking the question: does anybody use git-daemon for private code? If so, why are they not using SSH instead? And in that case, how are informative error messages a security risk? Tom -- 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
