Re: RFC: Separate commit identification from Merkle hashing

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 23, 2019, 20:09 UTC
Message-ID: <20190523200929.GA70860@google.com>
In-Reply-To: <86h89lq96v.fsf@gmail.com>

Hi,

Jakub Narebski wrote:

> I think Documentation/technical/hash-function-transition.txt misses
> considerations for fast-import format (it talks about problem with
> submodules, shallow clones, and currently not solved problem of
> translating notes; it does not talk about git-replace, either).

Hm, can you say more? I think fast-import is not significantly different from other tools that want to pick an appropriate object format for input and an appropriate object format for output.

Do you mean that the fast-import file should have a field for explicitly specifying the input object format, and that that doc ought to call it out?

[...]

Show 5 quoted lines

> For security, all references in Merkle-tree of hashes must use strong
> verification hash.  This means that you need to be able to refer to any
> object, including commit, by its verification hash name of its
> verification hash form (where all references inside object, like
> "parent" and "tree" headers in commit objects, use verification hashes).

This kind of crypto agility weakens any guarantees that rely on strength of a hash function. The security level would be that of the weakest of the supported hash functions.

In other words, usually the benefit of supporting multiple hash functions as a reader is that you want the strength of the strongest of those hash functions and you need a migration path to get there. If you don't have a way to eventually drop support for the weaker hashes, then what benefit do you get from supporting multiple hash functions?

Jonathan