On Thu, Apr 22, 2010 at 04:42:16AM -0500, Jonathan Nieder wrote: > > Thanks for the clarification. As I see it, these are two different > classes of problem: > > 1. The git daemon is very quiet, usually for good reason, as you > mentioned [1] [2]. > > 2. The git daemon and protocol helpers do not always send the datum “a > controlled fatal error occured” by writing some message (any > message) to side band 3. > > Fixing the daemon’s share in both might require setting up a side band > very early. If an RFC patch appears setting up the side band (or an > explanation for why that’s not possible), I would be happy to start > work building from there. There are few subcases of daemon-level errors: 1A) Invalid request No feedback is needed. These are protocol violations and well-behaved clients don't send these. 1B) Request for invalid repository These should have one error. That error can be sent using ERR response (already supported). 1C) Request for disabled service These too can be reported via ERR. One has to be careful not to create information leak using these. 1D) Catastrophic network error One can't do anything about these. 1E) Relay error Really shouldn't happen. Due to service state being unknown at time of things going wrong, one can't do much about these (what if relay error occurs in middle of packet? pad packet with zeroes?) So, pretty much the only daemon-level errors with feedback required would be one for invalid repository and disabled service. How about: "foo/example: unreadable or anonymous fetching not allowed." "foo/example: unreadable or anonymous pushing not allowed." "foo/example: unreadable or anonymous snapshotting not allowed." "fooserv: requested service unknown." And all of these can be sent over ERR. I don't see need for using sidebands. > That has been the big obstacle for me experimenting with it, more than > the information disclosure. But this is easy to say. The doing is > more important. -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