Re: [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 14, 2025, 22:49 UTC
Message-ID: <aO7Tgj4OJVLhFASW@fruit.crustytoothpaste.net>
In-Reply-To: <xmqqjz0xw20h.fsf@gitster.g>

On 2025-10-14 at 22:29:34, Junio C Hamano wrote:

Show 8 quoted lines

> I do not quite agree with that, as SHA-1 in patch-id is merely used
> as "a hash function with good distribution that we happened to have
> handy access to" without any security requirement.  Being able to
> compare patch IDs computed long ago stored somewhere with patch ID
> on a patch that claims to be freshly written and find them the same
> to say "you know, somebody wrote exactly the same patch 7 years ago"
> would be valuable, and we do not want to lose it even when you
> happen to store your payload in a SHA-256 repository.

I think that's too late, though. We already use SHA-256 in a SHA-256 repository, so people already expect that to work now and in the future. The time to make this decision would have been in 2020 with Git 2.29, but we now have people who will be using SHA-256 patch IDs and we need to support them.

We have also specifically discussed in the past people eventually wanting to compile Git without SHA-1 support at some point in the future for regulatory or compliance reasons, so we should full well expect that to happen and we'll need to be agile about the algorithm. SHA-1 will definitely disappear from at least some distributions of Git in the future.

Given that context, I think allowing the specification of an algorithm would allow people to say, "Yes, I am in a SHA-256 repository, but I want SHA-1," or vice versa, which would work with your use case better.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA