Re: Is GIT_DEFAULT_HASH flawed?

From: Junio C Hamano <gitster@pobox.com>
Date: May 9, 2023, 16:47 UTC
Message-ID: <xmqqild11mg6.fsf@gitster.g>
In-Reply-To: <ZFohLeq1AfdVKqfY@ugly>

Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:

Show 8 quoted lines

>>If your history contains mixed and matched hash algorithms, you'll need
>>to be able to verify those commits to the root to have any confidence in
>>a signed commit or tag, which means trusting SHA-1 if you have any SHA-1
>>commits in the repository.
>>
> the history is traversed from the end anyway, so having sha-1 in the
> history is entirely irrelevant for verifying sha-256 commits, assuming
> one may only upgrade the algorithm.

That depends on what is meant by "verify a commit". If we are only interested in the tree contents, then the newer commits whose trees are hashed with a more secure hash algorithm recursively down to the blobs would lack any weak link hashed by a less secure algorithm. Most people do not care as deeply how their project tree came to the shape it has today as they care about what is in the recent trees, so this is an acceptable stance to take.

If the less secure algorithm becomes so weak that the history, up to the last commit that was signed by it, can be rewritten arbitrarily, however, an attacker can lie about why the code that survives to this day looks the way it does by forging old parts of the history, and mislead today's developers to do wrong things. The only way to prevent that kind of attack is to verify a commit by recursively making sure not just the commit and its tree, but its parents are all authentic, and less secure algorithm may make it impossible.

The old history hashed with the old algorithm needs to be kept to help external references, but I think as a mitigation, those who care about that part of history can create a copy of the history hashed with the new algorithm and publish the correspondence between the two parallel histories to assure the integrity of that part of the old history.