Re: SHA256 support not experimental, or?

From: Patrick Steinhardt <ps@pks.im>
Date: Jun 30, 2023, 09:31 UTC
Message-ID: <vt3cizczmwbcpgktwrkr3jbiwhee37rt7m243hnkzxik7gt4m2@d2upsqoxtlgc>
In-Reply-To: <ZJ4uKYIZMxi3DHo3@tapette.crustytoothpaste.net>

On Fri, Jun 30, 2023 at 01:21:45AM +0000, brian m. carlson wrote:

Show 14 quoted lines

> On 2023-06-29 at 22:22:51, Junio C Hamano wrote:
> > True, and our messaging should avoid scaring them away from doing
> > so.  But isn't the lack of interoperability one of the reasons why
> > GitHub and Gitlab do not yet offer choice of the hash?  There
> > certainly is a chicken-and-egg problem here.
> 
> There are a lot of necessary changes for a forge to adopt SHA-256.  For
> example, at GitHub, we have a single null OID constant in some code that
> has to be addressed, libgit2 has to be taught about SHA-256 or removed,
> and UI changes need to be done to accommodate the larger IDs.  I'm
> sure that GitLab has very similar situations, as do all of the other
> forges.  After all, think about the extensive number of patches that
> went into Git itself to get us there.  Everyone has made all of those
> same assumptions in their forges.

Indeed, supporting SHA256 is a major effort on our side at GitLab. Most of the work isn't really adapting our production code, but it's rather that tons of tests were written with seed repositories and hardcoded object hashes. Converting all of that isn't all that hard in the general case, but it's a tedious job.

In the Gitaly team we have already started to put significant time into this problem and are slowly chipping away at it. We are at a state where most of our codebase works with SHA256 alright, and we in fact continue down that road as a low-priority side project where we convert a handful of tests every release.

> I'm certain that whether or not interoperability were available would
> not influence the forges' desire to support SHA-256.  It's simply a lot
> of work to fix all of those spots that need it and requires a lot of
> communication and discussions across teams, all of which takes time.

True as well. Even though Gitaly will likely be SHA256-ready in the not too distant future, that doesn't mean that GitLab as a whole is. The frontend will need investments as well, and there's likely a long tail of other stuff that needs to be done that I ain't yet got on my radar right now.

In any case I'm fully supportive of relaxing the current warning. Except for the recently discussed edge case where cloning empty repositories didn't create a SHA256 repository I have found the SHA256 code to be stable and working as advertised. We should caution people that many services will not work with SHA256 yet though.

Patrick