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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> Stefan Beller <sbeller@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]