From: Tian Yuchen <a3205153416@gmail.com>
To: Toon Claes <toon@iotcl.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
Patrick Steinhardt <ps@pks.im>,
git@vger.kernel.org
Subject: Re: [PATCH] hash: introduce support for the MD5 hash algorithm
Date: Thu, 2 Apr 2026 01:41:03 +0800 [thread overview]
Message-ID: <12070180-b0a1-4dcd-b333-3c42505aeecb@gmail.com> (raw)
In-Reply-To: <875x6aeqsa.fsf@toon--20250203-5JQV3.mail-host-address-is-not-set>
On 4/1/26 21:47, Toon Claes wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> On Wed, Apr 1, 2026, at 12:42, Patrick Steinhardt wrote:
>>> We are currently in the process of migrating to SHA256 as the
>>> alternative to SHA1. But we believe that proposal is misguided.
>>>
>>> When Linus first announced Git in April 2005, he was explicit about the
>>> role of SHA1 in the design: the hash is used for content integrity, not
>>> for cryptographic security [1]. Given this foundational principle, the
>>> collision resistance of the underlying hash algorithm is essentially
>>> irrelevant. What matters is that identical content always produces the
>>> same name, and that any corruption of stored data is detectable.
>>>
>>> While SHA256 technically provides stronger collision resistance than
>>> SHA1, it does so at the cost of 64-byte object names instead of 40, a
>>> 60% increase in verbosity for no practical benefit.
>>>
>>> As an alternative, MD5 satisfies the requirements of collision
>>> resistance and deterministic checksums perfectly well. At a length of 32
>>> hex characters they are shorter than SHA1, roll off the tongue more
>>> easily, and have been a beloved companion to the software engineer for
>>> decades. Furthermore, it remains in active use throughout the ecosystem,
>>> in checksums on download pages, filesystem integrity tools, and
>>> countless systems out there, which overall proves the point that they
>>> aren't inherently broken.
>>>
>>> Quoting Linus in [1]:
>>>
>>> In other words, I think we could have used md5's as the hash, if we
>>> just make sure we have good practices. And it wouldn't have been
>>> "insecure".
>>>
>>> Let's do so and wire up MD5 as a new alternatitve hash algorithm next to
>>> SHA1 and SHA256. Repositories can easily be initialized with MD5 by
>>> saying `git init --object-format=md5`, and tests can be executed with
>>> the new hash by setting the `GIT_TEST_DEFAULT_HASH_ALGO=md5` environment
>>> variable.
>>>
>>> [1]:
>>> https://lore.kernel.org/git/Pine.LNX.4.58.0504160913180.7211@ppc970.osdl.org/
>>>
>>> Signed-off-by: Patrick Steinhardt <ps@pks.im>
>>> ---
>>> Hi,
>>>
>>> I guess the title says it all. Let's correct course!
>>>
>>> Patrick
>>
>> I’ve been waiting years for this! Thank you so much!!!
MD5 sounds good... but Caesar cipher is clearly much better. This
approach offers O(N) performance, zero memory overhead, and — most
importantly — I want to be able to remember the key by heart.
To prevent unscrupulous individuals from directly deciphering the text
by aligning the letter 'e', I strongly recommend replacing all natural
language in the files and code with Japanese or Classical Chinese that
does not use particles.
By the way, it’d be better to switch the transport protocol to carrier
pigeons. Don't any of yall keep pigeons these days??
>
> I can't believe we'd have MD5 before GTA6.
>
Half-Life 3.
Regards, Yuchen
next prev parent reply other threads:[~2026-04-01 17:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 10:42 [PATCH] hash: introduce support for the MD5 hash algorithm Patrick Steinhardt
2026-04-01 10:54 ` Kristoffer Haugsbakk
2026-04-01 13:47 ` Toon Claes
2026-04-01 17:41 ` Tian Yuchen [this message]
2026-04-04 15:34 ` K Jayatheerth
2026-04-01 18:42 ` Junio C Hamano
2026-04-02 7:08 ` Patrick Steinhardt
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=12070180-b0a1-4dcd-b333-3c42505aeecb@gmail.com \
--to=a3205153416@gmail.com \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=ps@pks.im \
--cc=toon@iotcl.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