Re: [RFC PATCH 0/4] sign a SHA-256 digest of the tree in commits and tags

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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

Hi Scott & Patrick,

On Mon, 5 Oct 2026, Scott Chacon wrote:

> On Mon, Oct 5, 2026 at 2:41 PM Patrick Steinhardt <ps@pks.im> wrote:
>
> > The biggest problem I have is that the ecosystem has been entirely
> > unwilling to do anything about the SHA-256 move before we announced
> > that this is going to become mandatory. Only then were developers even
> > able to convince anybody (especially those paying the wages) to get
> > the time to implement support for it.
> 
> Bit of a simple question, but is it possible that this is because
> nobody really finds it a concerning problem?

I do agree that there has been an enormous reluctance to move to SHA-256.

One part is of course, that there was no sense of urgency, not even with
the SHAttered paper, because of the difficulty to apply it to Git objects
(which by happenstance rather than design made creating collisions
harder).

Out of curiosity, I researched the feasibility half a year ago: generating
two different `.c` files with the same blob OID where one of them carries
_some_ malicious payload (and an enormous number of seemingly random
bytes, carefully ensuring no NULs) would have a rough price tag of ~$10k
and a month of rented RTX 3090s. So that's not _purely_ theoretical, and
those numbers are likely lower today than half a year ago.

From my point of view, though, the much bigger part of the reluctance
stems from the ginormous amount of work required to migrate existing
repositories to SHA-256, and all that for little to no perceived benefit!

And it's not just an incredible amount of work, there are issues:

- Maintaining a local-only SHA-1 <-> SHA-256 mapping would be _required_
  for transition periods (forget about flag days, they are not feasible),
  and the resources (time!) are prohibitive for most serious data shapes.

- There are still no satisfying answers to the question how to deal with
  submodules. "Just use only SHA-1 or only SHA-256" is an answer that I
  heard as frequently as it is out of touch with reality: submodules often
  fetch from 3rd-party projects who don't exactly bend over to do what
  _you_ happen to need.

- There are still only absolutely unsatisfying answers to the question how
  to deal with partial or shallow clones. Unless you try flag days (which
  are, let's face it, practical only for ridiculously small teams).

- It is totally impossible to discern between a short SHA-1 and a short
  SHA-256. (No "this is SHA-256" prefix, or "first letter is an inverse
  hex digit" kind of discerning pattern there.)

  This has many corollaries, e.g.: The minimum hex digits for short OIDs
  changes substantially depending whether or not you have only one hash,
  or maintain a local mapping between SHA-1 <-> SHA-256. Just to name one.

There are many more issues with SHA-256 repositories, not least of which
that many a logic hard-codes "40 hex-digits" as the size of the hash.
Tooling. Services. Platforms. I know that the immediate reaction will be:
"Well, they should have prepared better!" which brings me back to
above-mentioned out-of-touch comment.

The worst part about this? The rationale that we need to switch to SHA-256
by default because SHA-1 makes Git repositories cryptographically weak
rarely matters in practice:

- The Git objects are already on The Server, in most cases. Let's face it,
  Git isn't used in a distributed manner. Most projects have their
  canonical central repository from which everybody clones. It would be
  simply impossible to replace existing objects with SHA-1-same copies on
  those servers.

- While many projects are developed in Git repositories, they are usually
  distributed via packages, including source packages, with separate
  actual cryptographic signatures. And those signatures are what matters,
  not Git's SHA-1.

- The well-known adage that the weakest link in the chain is what breaks
  it is quite true even in code security. It is pretty expensive (see
  above) to create SHA-1 collisions, especially ones that would not be
  spotted _immediately_. It is much, much easier to target the human
  element in the chain. You don't need SHA-1 collisions for that at all,
  just an overworked open source maintainer, and it is also much cheaper.

> > So there is some kind of ossification happening in the space. But
> > things are finally moving now that the due-date is drawing closer. I
> > would be extremely hesitant to change course again and drop this
> > breaking change now that there finally is some movement. Because the
> > only consequence of that would be that the ecosystem will stop working
> > on it again. And even more so, I would even expect that this will make
> > the next time we want to do a breaking change exponentially harder as
> > the lesson learned is that nobody needs to do anything.
> >
> > Maybe I'm too pessimistic about this, but I don't think so. We've been
> > working on this whole transition for almost a decade by now, and only
> > now where we're forcing the ecosystem to adapt are large players like
> > GitHub even moving.

I do agree that essentially only something like the "threat" of Git v3.0
switching to SHA-256 by default could have moved the industry players (and
not all of them, some of them still won't be able to support SHA-256, due
to the lack of funding for the work that would be required).

Having said that, I do think that we have to keep an open mind.

We need to keep the option open to decide "at the last minute" to satisfy
ourselves in Git v3.0 with having excellent support for SHA-256 and at the
same time _not forcing_ everybody and their cats to use it.

A feature like SHA-256 should probably be enabled only because users want
it, not because a few Git contributors want it so badly that they propose
to make it the default in v3.0. _The default_ should be switched to
SHA-256 only to solve a real problem that real users recognize and want to
see solved.

Ciao,
Johannes