git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Okhuomon Ajayi <okhuomonajayi54@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs
Date: Tue, 14 Oct 2025 22:49:38 +0000	[thread overview]
Message-ID: <aO7Tgj4OJVLhFASW@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqjz0xw20h.fsf@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2025-10-14 22:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 17:46 [PATCH] [PATCH] [Outreachy] builtin/patch-id.c: clarify SHA1 usage for patch IDs Okhuomon Ajayi
2025-10-14  3:00 ` Junio C Hamano
2025-10-14  8:04   ` Okhuomon Ajayi
2025-10-14 21:18 ` brian m. carlson
2025-10-14 22:29   ` Junio C Hamano
2025-10-14 22:49     ` brian m. carlson [this message]
2025-10-14 23:27       ` Okhuomon Ajayi
2025-10-15 13:37       ` Junio C Hamano
2025-10-15 13:59         ` Kristoffer Haugsbakk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aO7Tgj4OJVLhFASW@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=okhuomonajayi54@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).