git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Question About Git V2 Protocol & SHA256

From
Jeff King <peff@peff.net>
Date
Sep 30, 2020, 00:46 UTC
Message-ID
<20200930004630.GA623061@coredump.intra.peff.net>
In-Reply-To
<20200929224356.GH1392312@camp.crustytoothpaste.net>
On Tue, Sep 29, 2020 at 10:43:56PM +0000, brian m. carlson wrote:
Show 18 quoted lines
> On 2020-09-29 at 22:13:11, Jeff King wrote:
> > On Tue, Sep 29, 2020 at 01:17:59AM +0000, Wu, Zhichen wrote:
> > > 2. I see v2 has a capability called “object-format” that provides SHA1
> > >    option. I’m wondering if that capability will be the only way for
> > >    client and server to start using SHA256? Or put it as another word,
> > >    will v2 protocol be the prerequisite of SHA256?
> > 
> > I think it would be impossible to handle object-format via v1, because
> > the v1 protocol writes the ref advertisement before any capabilities are
> > negotiated. So I think v1 must implicitly remain sha1-only (and a sha256
> > repository on the server side would need to either reject a v1 client,
> > or back-translate as it would for a v2 client which asks for sha1).
> 
> I don't think that's the case.  You can indeed use v1 with SHA-256, but
> if you have a SHA-1-only Git, it will choke because the object ID is
> longer than it expects.  If you want to negotiate the algorithm when we
> support both and the client can't deal with translating the initial ref
> advertisement, then yes, you'll need v2.

I agree that we _could_ just dump sha256 within a v1 protocol and wait for the client to choke. But that seems like an awfully lousy user experience. By contrast, assuming that the client wants sha1 means that either:

  - we can reject it with a sensible ERR message that tells the user
    what is going on
  - we can serve them by talking in terms of sha1 if we're willing to
    do the extra conversion work server-side (and/or have a cache of
    sha1-format objects)

The only thing we lose is that a recent client who understands sha256 wouldn't be able to contact us and do a sha256-over-v1 transaction. But why would they want to do so?

This is all hypothetical at this point, though, right? I tried finding details in the hash transition document, but protocol changes are listed as out of scope there. It does say that sha256 servers may just reject sha1 clients; but even so I'd prefer if we could do it with a nice message (i.e., my bullet one above).

My suggestion does also require that we have a v2 receive-pack protocol, which does not yet exist (but following the blueprint for fetch, I don't expect it to be a big deal).

-Peff
Previous: Wu, ZhichenNext: brian m. carlson
Message 6 of 9 in “Question About Git V2 Protocol & SHA256”
  1. Wu, ZhichenSep 29, 2020
  2. Jeff KingSep 29, 2020
  3. Wu, ZhichenSep 29, 2020
  4. brian m. carlsonSep 29, 2020
  5. Wu, ZhichenSep 29, 2020
  6. Jeff KingSep 30, 2020
  7. brian m. carlsonSep 30, 2020
  8. Jeff KingSep 30, 2020
  9. brian m. carlsonOct 1, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.