On 2020-09-30 at 00:46:30, Jeff King wrote:
> 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)

If you have a suitably new Git, it will fail with an appropriate
message on both sides.  The client will complain that you are trying to
use a remote that uses the wrong hash algorithm and the server will
complain that you have failed to pass a suitable object-format
extension.  That will look like this:

  fatal: mismatched object format: server sha256; client sha1
  fatal: expected flush after ref listing

That's true if you're using protocol v2 at all, or a suitably new Git
with protocol v1, although the messages may differ slightly.  However,
if you're using an older Git with v1, then you'll get this:

  fatal: protocol error: unexpected '304c98b4860fa40b3e04f3e2e24db1a13ab959922a63209685813908c4fabc83 HEAD'
  fatal: the remote end hung up unexpectedly

That's because, as you pointed out, we don't get to the point where the
client fails to send the value.

> 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?

Because v2 isn't implemented for pushes yet.  The testsuite does not
even come close to passing unless you have a fully functional remote
system.  That's why I implemented protocol support, even though it
wasn't originally planned.

That was mentioned in the cover letter of the series that introduced
protocol support.

I should also point out that v2 SSH support doesn't work at all with
OpenSSH unless the server is specifically configured to allow the
GIT_PROTOCOL environment variable.  Since there are many use cases for
people to push Git data over SSH to servers they do not control, there
is a valid and viable use case for v1 support.  I personally know people
with shell accounts who could not use v2 over SSH but could viably use
v1.  Heck, that's even true for our shell host at work.

Absent a significant outreach campaign to all major operating system
vendors to get this environment variable added to all supported versions
of their OpenSSH packages, I don't see how restricting SHA-256 to
protocol v2 is acceptable.  Even then, many systems would still fail to
work correctly due to local config file modifications.

In retrospect, we probably should have sent "GIT_PROTOCOL=version=2" as
part of the shell command and let implementers deal with the fact that
their SSH servers would need to adequately parse and interpret shell
commands to function properly.  But it's probably too late to do that
now without bumping the protocol to v3.

> 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).

It is not hypothetical.  Git in master has a fully functional SHA-256
implementation that fully interoperates with other SHA-256 repositories.
As I mentioned above and elsewhere, that is a prerequisite for a fully
functional testsuite.  I would not have shipped user-visible SHA-256
support with a testsuite as broken as it would be without protocol
support.

> 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).

If someone would like to implement protocol v2 for push in time for
2.29, then that could be a viable approach if we can address the serious
problem of the SSH situation in that time frame as well.

I don't plan to implement v2 push support because that is a substantial
amount of work and I have even less time to work on Git than normal due
to taking classes multiple nights a week.  As I know you are aware,
working on Git is not my day job.

I will admit to being a bit annoyed that we're discussing changes like
this at this point.  I've tried to be open about the design and
implementation, answering questions and providing complete branches and
reasonably thorough cover letters that people can peruse to know what's
going on even if they aren't interested in the full series themselves.
LWN has even summarized some of the later work.  It's fine if folks
don't want to participate in that process, but it's hard to incorporate
feedback that comes in well after the fact.  I certainly hope the nature
and content of my SHA-256 work isn't a surprise to regulars on the list,
because I've clearly failed to communicate effectively if that's the
case.

I am at this point not planning any other major changes to SHA-256
support before the interop work starts to land.  I am of course happy to
address any bug reports that come up, and if others would like to send
in patches related to SHA-256, I will review them and provide feedback
as my time allows.
-- 
brian m. carlson: Houston, Texas, US