Jan Engelhardt <jengelh@xxxxxxx> writes: > Accessing a clone-only URL with a browser would always show a blank > page, because the reason string "Request is not supported" was "is not supported" -> "not supported", I think. > sent to the wrong file descriptor. I looked at the messages given to not_found() and forbidden(). Most of them do look like they are meant to be given to the remote user, but some reveal the server side paths, and I am reluctant to judge the security implication to start giving them, which have been hidden so far, to the remote users. I am not sure how strictly it is enforced these days, but at least in early days we were fairly paranoid and aimed to make sure that a remote user cannot tell a repository that does not exist from a repository that the user does not have access to by throwing random requests at the server. http-backend.c:161: forbidden(hdr, "Unsupported service: getanyfile"); This one should be safe, I would think. http-backend.c:184: not_found(hdr, "Cannot open '%s': %s", p, strerror(errno)); The 'p' is a path to a file in the repository like 'objects/alternates', that is ready to be given to open(2), so it clearly leaks the path on the server. http-backend.c:260: forbidden(hdr, "Unsupported service: '%s'", name); http-backend.c:271: forbidden(hdr, "Unsupported service: '%s'", name); http-backend.c:278: forbidden(hdr, "Service not enabled: '%s'", svc->name); These I think should be benign, but I have to admit that I didn't think too deep about them.
