Re: Fetching commit instead of ref

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 19, 2017, 16:07 UTC
Message-ID: <xmqqtvwmwvkp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1513672915856.50628@arris.com>

"Carlsson, Magnus" <Magnus.Carlsson@arris.com> writes:

> I understand that you don't want to allow people fetching single
> commits all the time, but is there a reason that you don't allow
> SHA instead of references when you fetch an entire tree?

I do not think we don't want to allow "single commit" fetch. We do not allow fetching histories from an arbitrary point in the graph, unless we can prove that what gets fetched is what the serving end intended to expose to the fetcher---you should view it as a security issue.

The default way to determine that a fetch request is getting only the things the serving end wanted to publish is to see the requested tips of the histories to be fetched are all pointed by refs. Which means that a client of a hosting site can rewind and repoint a ref after pushing a wrong branch that contained undesirable matter by accident. Moving the ref to make the undesirable object unreachable is all that is needed to "hide" it from the public view, even when the client does not have a way to trigger "gc" immediately on the hosting site.

There are variants of this security measure. If the hosting site is willing to spend extra cycles, we could loosen the "is the request fetching only what is published?" check to see if the requested tips are reachable from the tips of refs, instead of exactly at refs. It preserves "a mistake can be hidden with a forced push" property the same way as above, but it is costly and is prone to abuse.

If you are confident about your pushes all the time, you can take a stance "anything in the repository is meant to be read". That is what the "allowAnySHA1InWant" does. Not everybody however wants to do this for obvious reasons, so it is not a default.