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

["brian m. carlson" <sandals@crustytoothpaste.net>]

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

On 2026-10-05 at 14:16:48, Scott Chacon wrote:
> Thanks Steiny,
> 
> A quick response,

Hey,

> 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 think that's an oversimplification.  I think people don't realize that
Git is using SHA-1 and once SHA-256 is the default they will be very
much in favour of using it.  As I've said elsewhere in the thread, the
need to move away from SHA-1 is going to become gradually urgent for a
large segment of major institutions.

I can say that I've also had inquiries from large government agencies
and corporations and they very much know about SHA-256 and want it.
It's also very much desired by many in the open source community based
on feedback that I've received there.

To respond to what Patrick said, I think in general there is a huge
reluctance to invest in Git as an open source project and much open
source investment is driven by internal corporate needs.  As such,
there's been a huge investment in scaling Git and a lot less investment
in anything else, even if sometimes that ends up with less desirable
outcomes.  Customers get developers paged if their repositories don't
scale, but they don't page about SHA-256.  That doesn't mean it's not
important or valuable.

> > 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 want to remind everyone here quickly what "working on this whole
> transition for a decade" has looked like, because this seems to be
> phrased like everyone wanted this but GitHub was hesitant and pulled
> into this important work only by the heroic 3.0 breaking change
> decision.
> 
> GitHub has been essentially the _only one_ pushing this endeavour from
> the beginning of this problem set.

I will merely say in this regard that I don't speak in my corporate
capacity from this email address, so I don't think I'd like to respond
to this statement.  Patrick and I and the other contributors have
discussed SHA-256 and Git 3.0 at the Contributor's Summits in 2024,
2025, and 2026 and so I think there's a good understanding of where
different people and companies have been contributing to that and other
efforts.

What I will say is that my experience on SHA-256 is that it challenges a
lot of assumptions that people have built into their code over the years
and therefore any sort of migration to support SHA-256 involves a lot of
work, including substantial code changes and database migrations.  That
means that sometimes people have been doing substantial work behind the
scenes and it's just not visible until it's done.  You can see how this
works by looking at open source projects like libgit2 and gitoxide,
where extensive changes have landed over time.  My experience is that
reftable is another project where this is the case as well.

> If we assume Brian, Haggerty, Peff, Taylor and Derrick have been
> acting on behalf of GitHub, then you Steiny, are essentially the only
> major contributor to this project in the last decade that is not
> GitHub/MS (Eric maybe?). Very honestly, nobody else seems to care. GH
> has single handedly created this issue and then somehow simultaneously
> been the blocking factor to it's rollout because it also,
> simultaneously, does not really find it to be an actually important
> issue. Google maybe helped design the transition plan in 2017, but
> hasn't seemed to care too much since then. Nobody else has really
> weighed in, at least with patches.

I do want to clarify this, since I think there's a lot of confusion.
When I send contributions or patches from my personal email address,
they're personal contributions.  Only if the patches contain my work
address (which is extremely rarely) are they in my corporate capacity or
done on corporate time.

The SHA-256 work that I've been doing has almost exclusively been in my
personal capacity[0].  There is some of the interoperability work that I
was able to do on work time and those patches reflect the appropriate
email address and sign-off, but before that I have done almost no
SHA-256 work on company time.  This work has been done mostly on nights
and weekends, as with almost all of my other contributions, including on
the security list.  I contribute because I like the project and want it
succeed, not because I'm paid to do so.

I also want to state that I've received a great amount of assistance and
contributions, including reviews, patches, thoughtful ideas, and
miscellaneous assistance, from a wide variety of contributors to the
list and I could not have done it without them.  Someone who has only
provided reviews or design ideas has still aided the SHA-256 project and
Git as a whole immensely.  Patrick is just one of many people who have
aided in such a way.

As mentioned earlier, I am of course not going to comment on anything
related to my employer on any of this.  If you want their opinion, you
should ask them.

[0] The interested reader may wish to run the following command:
    git log --format='%ae' | grep -E '^(sandals|bk2204)@' | sort | uniq -c
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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