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

Hi Scott & Patrick,

On Mon, 5 Oct 2026, Scott Chacon wrote:

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.

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