Re: [BUG] commit walk machinery is dangerous !

[Nicolas Pitre <nico@cam.org>]

On Mon, 14 Jul 2008, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> 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