ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Can we fix the check in upload-pack.c something like my > patch below does? Are there any security implications for > doing that? > Could we just make the final check before dying if (!o) ? The primary implication is about correctness, so I am reluctant to break it without a careful alternative check in place. The issue is that having a single object in the repository does not guarantee that you have everything reachable from it, and we need that guarantee. Reachability from the refs is what guarantees that. We are careful to update the ref at the very end of the transfer (fetch/clone or push); so if an object is reachable from a ref, then all the objects reachable from that object are available in the repository. Imagine http commit walker started fetching tip of upstream into your repository and you interrupted the transfer. Objects near the tip of the upstream history are available after such an interrupted transfer. But a bit older history (but still later than what we had before we started the transfer) are not. We do not update the ref with the downloaded tip object, so that we would not break the guarantee. This guarantee is needed for feeding clients from the repository later. If you tell your clients, after such an interrupted transfer, that you are willing to serve the objects near the (new) tip, the clients may rightfully request objects that are reachable from these objects, some of them you do _not_ have! So this "on demand SHA1" stuff needs to be solved by checking if the given object is reachable from our refs in upload-pack, instead of the current check to see if the given object is pointed by our refs. When upload-pack can prove that the object is reachable from one of the refs, it is OK to use it; otherwise you should not. Now, proving that a given SHA1 is the name of an object that exists in the repository is cheap (has_sha1_file()), but proving that the object is reachable from some of our refs can become quite expensive. That gives this issue a security implication as well -- you can easily DoS the git-daemon that way, for example. - : 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