On 04/22/2010 11:42 AM, Jonathan Nieder wrote: > Junio C Hamano wrote: > >> The true story is a bit different. >> >> To avoid information leak to git-daemon clients, we deliberately choose >> not to give detailed error messages, so that you cannot tell if an error >> means a user "u" does not exist or "u" does but ~u/repo.git repository >> does not exist. > > 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. > > [1] I do suspect that in the case of failing enter_repo() or missing > git-daemon-export-ok, saying “cannot read the specified repo” would be > fine. Most of the time, there is not much value in disclosing a more > detailed reason, anyway. > That would make it possible for random attackers to determine whether a specific user exists on the system, which is very bad indeed. > [2] Example fix for a problem in this class: > http://thread.gmane.org/gmane.comp.version-control.git/139029 That's a different problem. We only end up in {send,receive}-pack if the remote user asked for an existing repository, which means he or she is either a very determined guesser or, more likely, already knows that the user exists and where he or she keeps git repos. A possible issue, to be sure, but definitely a far narrower window than just guessing a username. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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