Hi, Brandon Williams wrote:
> Given some of this discussion though, maybe we want to change the > semantics of 'protocol.version' so that both servers and clients respect > it. As of right now, these patches have the server always allow > protocol v0 and v1? Though that doesn't do much right now since v1 is > the same as v0. I strongly prefer not to do that. If we want to make the advertised protocol versions on the server side configurable, I think it should be independent from the configuration for protocol versions to use on the client side. Rationale: - As a client-side user, I may want to (after reporting the bug, of course!) blacklist certain protocol versions to work around server bugs. But this should not affect my behavior as a server --- in my role as a server, these server-side bugs have no effect on me. - As a server operator, I may want to (after reporting the bug, of course!) blacklist certain protocol versions to work around client bugs. But this should not affect my behavior as a client --- in my role as a client, these client-side bugs have no effect on me. Making the client-side case configurable seems important since Git is widely used in environments where it may not be easy to control the deployed version (so having configuration as an escape hatch is important). Making the server-side case configurable seems less important since Git server operators usually have tight control over the deployed Git version and can apply a targetted fix or workaround. > One other considerations that I should probably handle is that a client > doesn't do any verification right now to ensure that the protocol > version the server selects was indeed the protocol that the client > requested. Is that something you think we need to check for? Do you mean in tests, or are you referring to something else? Thanks, Jonathan
