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

Stefan Beller [off-list ref] writes:

quoted

quoted

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

On Wed, Jul 13, 2016 at 03:41:01PM -0700, Junio C Hamano wrote:

Stefan Beller [off-list ref] writes:

quoted

quoted

quoted

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