[PATCH 0/3] don't let disk corruptions escape pack SHA1 checksum

[Nicolas Pitre <nico@xxxxxxx>]

On Wed, 27 Aug 2008, Nicolas Pitre wrote:

> On Wed, 27 Aug 2008, Linus Torvalds wrote:
> 
> > However, we do have this odd case of fixing up the pack after-the-fact 
> > when we receive it from somebody else (because we get a thin pack and 
> > don't know how many objects the final result will have). And that case 
> > seems to be not as safe, because it
> > 
> >  - re-reads the file to recompute the SHA1
> > 
> >    This is understandable, and it's fairly ok, but it does mean that there 
> >    is a bigger chance of the SHA1 matching if something has corrupted the 
> >    file in the meantime!
> 
> I think that can be fixed.  When reading the file back, it is possible 
> to compute 2 sha1s: one to compare with the recieved one using original 
> pack header, and the second which would be the final one.  FRom a 
> certain offset, new objects were added, so that first sha1 is validated 
> against the received one and reset, and at the end, it should correspond 
> to the sha1 of added objects that we should compute when writing them.

So here is 3 patches for this in C git (Shawn already did it for jgit).

There are 3 spots where this needs to be plugged: in pack-objects, 
index-pack and fast-import.  I did the first two.

I don't think this is that pertinent in fast-import because:

 - we want fast-import to be fast

 - after fast-import is done, a full repack is typically done which 
   would revalidate everything (maybe fast-import should use index v2 
   with its per object CRC32 though)

But maybe I'm wrong about that. In any case, I am leaving the 
fast-import to someone more knowledgeable about its code than I do.

Nicolas Pitre (3):
      improve reliability of fixup_pack_header_footer()
      pack-objects: use fixup_pack_header_footer()'s validation mode
      index-pack: use fixup_pack_header_footer()'s validation mode


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