Re: Is GIT_DEFAULT_HASH flawed?

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: May 9, 2023, 10:32 UTC
Message-ID: <ZFohLeq1AfdVKqfY@ugly>
In-Reply-To: <ZFlr8PWOPRuLuP6E@tapette.crustytoothpaste.net>

On Mon, May 08, 2023 at 09:38:56PM +0000, brian m. carlson wrote:

Show 18 quoted lines

>On 2023-05-08 at 02:00:56, Felipe Contreras wrote:
>> brian m. carlson wrote:
>> > On 2023-05-02 at 23:46:02, Felipe Contreras wrote:
>> > > In my view one repository should be able to have part SHA-1 history,
>> > > part SHA3-256 history, and part BLAKE2b history.
>> > 
>> > That is practically very difficult and it means that it's hard to have
>> > confidence in the later history because SHA-1 is weak and you have to
>> > rely on it to verify the SHA-256 history later.
>> 
>> Why would I have to rely on SHA-1 to verify the SHA-256 history later
>> on?
>
>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.

the transition plan implies the intent to ultimately get rid of old algos, but this is a non-starter, because old histories need to remain accessible indefinitely (you can't rewrite all external references, and even for in-history references this would be unreliable and would falsify historical builds).

i won't try making an argument for mixed histories, as i'm assuming i wouldn't add anything that hasn't already been written.

-- ossi