Re: What's cooking in git.git (Jul 2016, #05; Wed, 13)

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 13, 2016, 22:41 UTC
Message-ID: <xmqqinw9yxdu.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYUMX7wewo2QEWQGU9sGR76XjrKJ3uJxpLnyWoZeZ6WXA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 17 quoted lines

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

As to the "SQUASH???" compilation fix, I can squash it to the one immediately below it locally; I didn't do so in today's pushout, as it was still unclear if you are already working on a reroll (in which case anything I would do would be a wasted effort).