On Mon, 14 Jul 2008, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > > However this time a corruption turned up and exposed what I think is a > > major flaw in git's error checking. To demonstrate it, I created the > > following test case. Turning the error() into a die() on line 772 of > > commit.c makes this test pass but I don't know if this is the > > appropriate fix (e.g. some attempt to parse non existing commits could > > be valid usage, etc.). Note this is critical only for git versions > > later than commit 8eca0b47ff15. > > Which probably means we should revert that commit as faulty? IIRC, before > that commit we did check and error out correctly but you loosened the > check to introduce "a major flaw" with that commit. > > $ for b in maint master next pu > do > echo -n $b; git cat-file blob $b:commit.c | wc -l > done > maint 672 > master 672 > next 779 > pu 789 > > Hmph... Well, most of them aren't that critical. If anything they will only cause a segfault if ever the return value is not checked. It is those with semantic meaning (e.g. object doesn't exist) which should be audited, especially if used in the context of repository modification, which pretty much limits it to the test case I produced. Nicolas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
