summaryrefslogtreecommitdiff
path: root/sha1_file.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2017-01-13 18:00:25 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-01-15 23:59:03 (GMT)
commitcce044df7f2392d0c6cb21d6dca94f01ff838727 (patch)
treebf624d600e7424d9ca66b05712bc2dc7debb9cf1 /sha1_file.c
parentc68b489e56431cf27f7719913ab09ddc62f95912 (diff)
downloadgit-cce044df7f2392d0c6cb21d6dca94f01ff838727.zip
git-cce044df7f2392d0c6cb21d6dca94f01ff838727.tar.gz
git-cce044df7f2392d0c6cb21d6dca94f01ff838727.tar.bz2
fsck: detect trailing garbage in all object types
When a loose tree or commit is read by fsck (or any git program), unpack_sha1_rest() checks whether there is extra cruft at the end of the object file, after the zlib data. Blobs that are streamed, however, do not have this check. For normal git operations, it's not a big deal. We know the sha1 and size checked out, so we have the object bytes we wanted. The trailing garbage doesn't affect what we're trying to do. But since the point of fsck is to find corruption or other problems, it should be more thorough. This patch teaches its loose-sha1 reader to detect extra bytes after the zlib stream and complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'sha1_file.c')
-rw-r--r--sha1_file.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/sha1_file.c b/sha1_file.c
index ca1c90e..b2c6648 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3847,6 +3847,11 @@ static int check_stream_sha1(git_zstream *stream,
error("corrupt loose object '%s'", sha1_to_hex(expected_sha1));
return -1;
}
+ if (stream->avail_in) {
+ error("garbage at end of loose object '%s'",
+ sha1_to_hex(expected_sha1));
+ return -1;
+ }
git_SHA1_Final(real_sha1, &c);
if (hashcmp(expected_sha1, real_sha1)) {