upload-pack: load non-tip "want" objects from disk
commitf59de5d1ff9b0f9d570df99128f41520a281f9a5
authorJeff King <peff@peff.net>
Sat, 16 Mar 2013 10:28:30 +0000 (16 06:28 -0400)
committerJunio C Hamano <gitster@pobox.com>
Sun, 17 Mar 2013 05:19:29 +0000 (16 22:19 -0700)
tree117f4c2ff32ce1f5e6a9793e1609995109f2fdf4
parent06f15bf1f340f37293b471d8556842d4e89ff63f
upload-pack: load non-tip "want" objects from disk

It is a long-time security feature that upload-pack will not
serve any "want" lines that do not correspond to the tip of
one of our refs. Traditionally, this was enforced by
checking the objects in the in-memory hash; they should have
been loaded and received the OUR_REF flag during the
advertisement.

The stateless-rpc mode, however, has a race condition here:
one process advertises, and another receives the want lines,
so the refs may have changed in the interim.  To address
this, commit 051e400 added a new verification mode; if the
object is not OUR_REF, we set a "has_non_tip" flag, and then
later verify that the requested objects are reachable from
our current tips.

However, we still die immediately when the object is not in
our in-memory hash, and at this point we should only have
loaded our tip objects. So the check_non_tip code path does
not ever actually trigger, as any non-tip objects would
have already caused us to die.

We can fix that by using parse_object instead of
lookup_object, which will load the object from disk if it
has not already been loaded.

We still need to check that parse_object does not return
NULL, though, as it is possible we do not have the object
at all. A more appropriate error message would be "no such
object" rather than "not our ref"; however, we do not want
to leak information about what objects are or are not in
the object database, so we continue to use the same "not
our ref" message that would be produced by an unreachable
object.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack.c