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
