This patch series introduces detailed checking of tag objects when calling git fsck, and also when transfer.fsckobjects is set to true.
To this end, the fsck machinery is reworked to accept the buffer and size of the object to check, and for commit and tag objects, we verify that the buffers contain an end of header (i.e. an empty line) to guarantee that our checks do not run beyond the buffer. This work was sponsored by GitHub. Changes since v2: - replaced 'invalid message' with 'unterminated header' - avoided comparison between int and unsigned long (thanks, Eric Sunshine) - made ident parsing conditional on finding the optional 'tagger' line - added forgotten strbuf_release() Still unaddressed: - getting rid of struct object altogether in fsck (I felt this was quite a big task, getting much more familiar with the non-tag code paths, and I did not want to delay this patch series up any further) - ensuring that index-pack passes only NUL-terminated buffers to fsck (again, I am not familiar enough with the code, and IIRC the problematic unit test that revealed that these buffers are not always NUL-terminated exercised the unpack-objects code path, not index-pack, again nothing I wanted to let delay this patch series any further). Johannes Schindelin (6): Refactor type_from_string() to avoid die()ing in case of errors Accept object data in the fsck_object() function Make sure fsck_commit_buffer() does not run out of the buffer fsck: check tag objects' headers Add regression tests for stricter tag fsck'ing Make sure that index-pack --strict checks tag objects builtin/fsck.c | 2 +- builtin/index-pack.c | 3 +- builtin/unpack-objects.c | 14 +++-- fsck.c | 133 +++++++++++++++++++++++++++++++++++++++++++---- fsck.h | 4 +- object.c | 11 +++- object.h | 3 +- t/t1450-fsck.sh | 20 +++++++ t/t5302-pack-index.sh | 19 +++++++ 9 files changed, 189 insertions(+), 20 deletions(-) -- 2.0.0.rc3.9669.g840d1f9 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
