Re: weaning distributions off tarballs: extended verification of git tags

From: Sam Vilain <sam@vilain.net>
Date: Mar 2, 2015, 20:52 UTC
Message-ID: <54F4CD79.4080209@vilain.net>
In-Reply-To: <xmqqwq2z9n7c.fsf@gitster.dls.corp.google.com>

On 03/02/2015 12:08 PM, Junio C Hamano wrote:

Show 17 quoted lines

>> I have a
>> hazy recollection of what it would take to replace SHA-1 in git with
>> something else; it should be possible (though tricky) to do it lazily,
>> where a tree entry has bits (eg, some of the currently unused file
>> mode bits) to denotes which hash algorithm is in use for the entry.
>> However I don't think that got past idea stage...
> I think one reason why it didn't was because it would not work well.
> That "bit that tells this is a new object or old" would mean that a
> single tree can have many different object names, depending on which
> of its component entries are using that bit and which aren't.  There
> goes the "we know two trees with the same object name are identical
> without recursing into them" optimization out the window.
>
> Also it would make it impossible to do what you suggest to Joey to
> do, i.e. "exactly the same way that git does", once you start saying
> that a tree object can be encoded in more than one different ways,
> wouldn't it?

I was reasoning that people would rather not have to rewrite their whole history in order to switch checksum algorithms, and that by allowing trees to be lazily converted that this would make things more efficient. However, I think I see your point here that this doesn't work.

However, as a per-commit header, then only first commit which changes the hashing algorithm would have to re-checksum each of the files: but just in the current tree, not all the way back to the beginning of history. The delta logic should not have to care, and these objects with the same content but different object ID should pack perfectly, so long as git-pack-objects knows to re-checksum objects with the available hash algorithms and spot matches.

Other operations like diff which span commit hashing algorithms might be able to get away with their existing object ranking algorithms and cache alternate object IDs for content as they operate to facilitate exact matching across hash algorithm changes.

But actually, for the original problem - just producing a signature with a different hashing algorithm - probably it would be sufficient to just re-hash the current commit and the current tree recursively, and the mixed hash-algorithm case does not need to exist. But I'm just thinking it might not be too hard to make git nicely generic, to be well prepared for when a second pre-image attack on SHA-1 becomes practical.

Sam