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

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Mon, Oct 5, 2026, at 14:41, Patrick Steinhardt wrote:
> On Mon, Oct 05, 2026 at 11:32:54AM +0200, Scott Chacon wrote:
>> On Fri, Oct 2, 2026 at 9:06 PM brian m. carlson
>> <sandals@crustytoothpaste.net> wrote:
>> > On 2026-10-02 at 08:18:42, Scott Chacon wrote:
> [snip]
>> > Every major forge has support
>> > for SHA-256, whether publicly or in preview,
>>
>> Nobody has access to this for GitHub, which is where almost all usage
>> is and where the kinks could theoretically have been ironed out. If
>> 3.0 comes out in March, there will have been no time for anyone to
>> give feedback or make substantial changes before everyone is forced
>> into real usage of this highly incompatible change.
>>
>>[snip even more]
>>
>> As one small but interesting example, I'm honestly fascinated that
>> there is only now a thread here about the GitHub specific usability
>> issues [2] with mixed odb repos (between several GitHub-y people,
>> nonetheless) that hasn't been previously considered (the "limbo"
>> idea). This is the kind of thing (among many others, I'm sure) that
>> would come up if people had time to use this at all before a default
>> switch.
>
> 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.
>
> 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.

The wider ecosystem is one thing. But git(1) itself doesn’t seem
ready at all.

A few days ago, having read Scott Chacon’s blog post and discussions
around it,[1] I wanted to test migrating the Git repo to SHA-256. So how
do I do that? I google around and the most official “transition” program
seems to be this.

https://git-scm.com/docs/hash-function-transition

I.e. a document where you can’t really tell the implementation from the
aspiration.

† 1: It seems he has never linked it here on the list, like in this
     thread.

But okay, the *real* program to convert a repository seems to be

    git fast-export --all

And that was okay. The Git repo seems to have a bit of cruft, and
git-fast-export(1) fails on the first error then suggests a fix so that
you can continue on to the next error. But that’s fine for a one-shot
program. For anyone interested:

    git fast-export --all --reencode=yes --mark-tags \
        --signed-tags=verbatim \
        --tag-of-filtered-object=rewrite >SHA1HERE

Some real loss of fidelity was there though:

1. You can’t for some reason export refs that point to blobs or trees
2. Your Git notes will be effectively lost since they will retain their
   SHA-1 filenames. (This is mentioned in hash-function-transition)

Then you import it with

    git fast-import

But to no one’s surprise (here) this does not work because of the SHA-1
collision submodule.

Okay, dropping that exercise for a second. I would personally be okay
with trying out this migration on my existing repos that are “local
only”. It would clearly be in my interest to find any bugs that are
particular to my workflows. But for that I would that migration where
you keep a mapping of SHA-1 to SHA-256. Or else I will lose Git notes
forever (which I use a lot).

But reading brian’s cousin response:
<asQrWAKQXV9zn1Vq@fruit.crustytoothpaste.net> ... it seems that there is
not enough in git(1) or anywhere else to do that.

So what is anyone outside the group of guts-of-Git developers supposed
to do? It seems we just have to wait until Git 3.0 and see what happens.

And then you can imagine Git 3.0. Someone happens to make a new Git
repository and they use it for three days without trying to push it
somewhere to SHA-1-Only land. But then they do. And the forge has at
least implemented a nice, informative error message. The user only cares
that “a week ago it worked” and “now it is broken”. (“broken”
subjectively.) He feeds it to some oracle and it turns out that they
just need a few commands to convert back to SHA-1, then one command to
turn off the default. Now they have mitigated the “broken Git” problem
for themselves. And what have they lost? It’s not even a hack.

Then zoom out and you might have the wider ecosystem, like forges.
If they don’t implement it in time? Well, maybe that informative error
message becomes:

    remote: unsupported hash algorithm
    remote: if this is your first push of a local repo, here’s
    remote: how to convert your repo to SHA-1:
    remote: <commands>
    remote: and here’s how to turn off this default [...]

Then someone will post that as a question on StackOverflow, get flamed
because the error message “says how to fix it”, get 3000 upvotes, and
the world moves drunkenly on.

The above scenario would be very hyperbolic and too cynical if not for
the context: one person is leading the direct implementation work[2] in
their spare time. In order to migrate Git from a to-be government-wide
banned hash algorithm. That seems like an institutional malfunction.
Somewhere.

To reiterate, there doesn’t seem like there is anything for us
above-average Git-interested users to do yet. So it feels like we
just have to wait until March or a little later, see if the default-
SHA-256 change lands, and see what the fallout is. And that is a bit
frustrating.

† 2: This is to acknowledge that there are other people like reviewers