Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)
- From
Jeff King <peff@peff.net>
- Date
- Jul 13, 2016, 22:42 UTC
- Message-ID
- <20160713224256.GA8980@sigill.intra.peff.net>
- In-Reply-To
- <xmqqinw9yxdu.fsf@gitster.mtv.corp.google.com>
On Wed, Jul 13, 2016 at 03:41:01PM -0700, Junio C Hamano wrote:
Show 24 quoted lines
> Stefan Beller <sbeller@google.com> writes: > > >>> I think Shawns proposal to have a receive.maxCommandBytes is a > >>> good way for an overall upper bound, but how does it stop us from > >>> going forward with this series? > >> > >> If we were to do maxcommandbytes, then max_options would become > >> irrelevant, no? > > > > Maybe? > > > > I do not know what kind of safety measures we want in place here, and > > if we want to go for overlapping things? > > > > Currently there are none at all in your upstream code, although you cannot > > push arbitrary large things to either Shawns or Peffs $Dayjob servers, so > > I wonder if we want to either agree on one format or on many overlapping > > things, as some different hosts may perceive different things as DoS threats, > > so they can fine tune as they want? > > I think those extra knobs can come later. If we are not going to > limit with max_options in the end, however, wouldn't it be more > natural for the initial iteration without any configuration not to > have hard-coded max_options at all?
Yeah, I am OK with adding restrictive knobs later as a separate topic. As Stefan notes, upstream does not have the other knobs anyway, and IIRC the push-options feature is not even enabled by default.
-Peff