Re: [PATCH v3 03/10] protocol: introduce protocol extention mechanisms
- From
Simon Ruderich <simon@ruderich.org>
- Date
- Oct 6, 2017, 09:09 UTC
- Message-ID
- <20171006090907.gbsgygulzj3bgqrg@ruderich.org>
- In-Reply-To
- <20171003201507.3589-4-bmwill@google.com>
On Tue, Oct 03, 2017 at 01:15:00PM -0700, Brandon Williams wrote:
Show 9 quoted lines
> [snip] > > +protocol.version:: > + Experimental. If set, clients will attempt to communicate with a > + server using the specified protocol version. If unset, no > + attempt will be made by the client to communicate using a > + particular protocol version, this results in protocol version 0 > + being used. > + Supported versions:
Did you consider Stefan Beller's suggestion regarding a (white)list of allowed versions?
On Mon, Sep 18, 2017 at 01:06:59PM -0700, Stefan Beller wrote:
Show 10 quoted lines
> Thinking about this, how about: > > If not configured, we do as we want. (i.e. Git has full control over > it's decision making process, which for now is "favor v0 over v1 as > we are experimenting with v1". This strategy may change in the future > to "prefer highest version number that both client and server can speak".) > > If it is configured, "use highest configured number from the given set". > > ?
It would also allow the server operator to configure only a specific set of versions (to handle the "version x is insecure/slow"-issue raised by Stefan Beller). The current code always uses the latest protocol supported by the git binary.
Minor nit, s/extention/extension/ in the patch name?
Regards Simon
-- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9