]> git.ipfire.org Git - thirdparty/git.git/commit - commit.c
parse_commit_buffer(): treat lookup_commit() failure as parse error
authorJeff King <peff@peff.net>
Fri, 18 Oct 2019 04:42:13 +0000 (00:42 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 21 Oct 2019 02:15:23 +0000 (11:15 +0900)
commitc78fe00459d49cd57cbfabc5c564af0cb9a934f1
tree0e6dab31b2ce80a184e8d121424e7081a82ae0f6
parentd966095db01190a2196e31195ea6fa0c722aa732
parse_commit_buffer(): treat lookup_commit() failure as parse error

While parsing the parents of a commit, if we are able to parse an actual
oid but lookup_commit() fails on it (because we previously saw it in
this process as a different object type), we silently omit the parent
and do not report any error to the caller.

The caller has no way of knowing this happened, because even an empty
parent list is a valid parse result. As a result, it's possible to fool
our "rev-list" connectivity check into accepting a corrupted set of
objects.

There's a test for this case already in t6102, but unfortunately it has
a slight error. It creates a broken commit with a parent line pointing
to a blob, and then checks that rev-list notices the problem in two
cases:

  1. the "lone" case: we traverse the broken commit by itself (here we
     try to actually load the blob from disk and find out that it's not
     a commit)

  2. the "seen" case: we parse the blob earlier in the process, and then
     when calling lookup_commit() we realize immediately that it's not a
     commit

The "seen" variant for this test mistakenly parsed another commit
instead of the blob, meaning that we were actually just testing the
"lone" case again. Changing that reveals the breakage (and shows that
this fixes it).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit.c
t/t6102-rev-list-unexpected-objects.sh