From: Oswald Buddenhagen Date: Tue, 09 May 2023 10:32:13 GMT Subject: Re: Is GIT_DEFAULT_HASH flawed? Message-ID: In-Reply-To: On Mon, May 08, 2023 at 09:38:56PM +0000, brian m. carlson wrote: >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