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

From: Okhuomon Ajayi <okhuomonajayi54@gmail.com>
Date: Oct 14, 2025, 23:27 UTC
Message-ID: <CAFpMFfCV0-MHDYDuVz81hdvBN8qoyse=Hie1rF5=qPOigPM67Q@mail.gmail.com>
In-Reply-To: <aO7Tgj4OJVLhFASW@fruit.crustytoothpaste.net>

Hi Junio, Brian,

Thanks a lot for the detailed explanations this gave me a much better understanding of the history behind patch-id and why the hash choice isn’t straightforward.

I see now that just forcing SHA-1 isn’t ideal since patch-id already uses the repo’s hash in SHA-256 repos. I’ll take another look at how the computation works in the other paths and think about how to handle it better, maybe by adding an option or clarifying the behavior.

Really appreciate you both taking the time to explain I’m learning a lot from this.

On Tue, Oct 14, 2025 at 11:49 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 30 quoted lines

>
> On 2025-10-14 at 22:29:34, Junio C Hamano wrote:
> > 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