Re: [RFC][PATCH] Allow transfer of any valid sha1

[Junio C Hamano <junkio@cox.net>]

ebiederm@xmission.com (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.