Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57221
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <4F052C10.30106@lerdorf.com>
References: <CABBJUpc7T2QZm8QiitQ0wZ5RsY=3Jwy_UERSvLT9unNYtJ1mZA@mail.gmail.com>
 <CABBJUpeN4iJ6mVUKEEz8qxY25zxTmwg8EigpsmxnZGz5xshMhw@mail.gmail.com>
 <4F048A03.4070408@sugarcrm.com> <CAH-PCH69gV88qnQ7OHhGHSt70oD7f9Z_HCFD7dfW6SmBR6z2tQ@mail.gmail.com>
 <4F04A172.7080509@sugarcrm.com> <CAH-PCH5BUsrXKLtk6JWCOA8d5+2DxSke3UAnbBraJyGP-YnQnA@mail.gmail.com>
 <4F04AA8E.6020701@sugarcrm.com> <CAH-PCH6YH3ZxH5XzEm6+gsikaHjyL-pdHyAs=OnFhWqHk0CctQ@mail.gmail.com>
 <4F04AD6D.80608@php.net> <CAF+90c-6XrWJnL4vOQjjPm=N=fWrMy31wHOeXGccv+KRq5DrVw@mail.gmail.com>
 <4F04B071.8080102@php.net> <CAKxcST9NhATxVLrOVP9h2Qy9GfuuzreeVMBtH0EqdZf7jPhytg@mail.gmail.com>
 <4F04B44D.6080208@thelounge.net> <4F04BCF9.30802@lerdorf.com>
 <CAH-PCH5NLbDH9K3abJ70Z0AMjfwRNcjk5xE6aSs4cvpBR2_k5Q@mail.gmail.com>
 <4F04BF63.5060309@lerdorf.com> <4F04C427.9050202@sugarcrm.com>
 <4F04C920.9050105@lerdorf.com> <4F04CB0D.6040703@lerdorf.com>
 <CABBJUpcXFChrODjdXzhm-_qLZ7sNSQNAEWCJY_BCvXAWPxbPaA@mail.gmail.com> <4F052C10.30106@lerdorf.com>
Date: Thu, 5 Jan 2012 13:01:40 +0800
Message-ID: <CABBJUpf3Z=cV_eooJF8fnALM+o9uj3x_qusynjs6iG1nUfQoMA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	Reindl Harald <h.reindl@thelounge.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: another fix for max_input_vars.
From: laruence@php.net (Laruence)

On Thu, Jan 5, 2012 at 12:50 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 01/04/2012 08:13 PM, Laruence wrote:
>> On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrot=
e:
>>> On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote:
>>>> On 01/04/2012 01:27 PM, Stas Malyshev wrote:
>>>>> Hi!
>>>>>
>>>>>> Right, like I said in my previous message, if this is caught by
>>>>>> display_start_errors, I am ok with it. We need the default/no php.in=
i
>>>>>> file case to not leak information like this.
>>>>>
>>>>> Just checked - it does not display error if display_startup_errors if
>>>>> off, does display if it's on.
>>>>
>>>> Right, that seems ok. The other thing is that we need to clarify that =
it
>>>> actually only limits the number of variables per nesting level. The
>>>> current name and the description doesn't make that clear. You can stil=
l
>>>> send 1M post vars in a single POST if you just nest them in a 1000x100=
0
>>>> 2d array. Of course, this is likely going to hit the post_max_size
>>>> limit, although many sites that do file uploads will have cranked that
>>>> way up.
>>>
>>> Oh, and a final issue to address.
>>>
>>> This code:
>>>
>>> for($data=3D[],$i=3D0; $i<=3D999; $i++) $data[$i] =3D range(0,1001);
>>> echo curl_post("http://localhost/index.php",['a'=3D>$data]);
>>>
>>> will spew the warning 2000 times.
>>>
>>> & php post.php | grep Warning | wc -l
>>> 2000
>>>
>> could you try with this new patch:
>> https://bugs.php.net/patch-display.php?bug_id=3D60655&patch=3Dmax_input_=
vars.patch&revision=3Dlatest
>> ?
>>
>> this patch also restrict the json / serializer , =C2=A0all of them must
>> less than PG(max_input_vars).
>>
>> and different with the fix which was commited now, =C2=A0this patch coun=
t
>> the num vars in a global scope, that means if there are 2 elements
>> which both have 500 elements in post, =C2=A0the restriction will also
>> affect,
>>
>> and this patch will not affect the existsing called to json or
>> serializer, =C2=A0 only affect the zif_json_decode and zif_serialize,
>> after patch, the serialize will have a sencode parameter :"$max_vars".
>>
>> and the restriction can also be closed by set max_input_vars to 0.
>
> Right, I don't think this is going to work. A simple 'make install'
> after applying your patch fails with:
>
> Warning: unserialize(): Unserialized variables exceeded 1000 in
> phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.pha=
r/PEAR/Registry.php
> on line 1145
>
> Warning: unserialize(): Unserialized variables exceeded 1000 in
> phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.pha=
r/PEAR/Registry.php
> on line 1145
>
> Warning: unserialize(): Unserialized variables exceeded 1000 in
> phar:///home/rasmus/php-src/branches/PHP_5_4/pear/install-pear-nozlib.pha=
r/PEAR/Registry.php
> on line 1145
> [PEAR] PEAR: pear.php.net/PEAR not installed
>
> I really don't think this manual per-feature limiting is going to cut it
> here. The real problem is the predictability of the hashing which we can
> address by seeding it with a random value. That part is easy enough, the
Hi:
  that will be a better fix, we have disscussed this before in irc,  I
also can have a try in that way.

  and for this fix(in such way), to be honest, yes, this is a little
ugly fix, but quick.

  the default 1000 is a little insufficient when counting the elements
in a global scope.

  IMO it should set to be 4096,  then I think 99% of developers will
not see this warning at all.

thanks

> hard part is figuring out where people may be storing these hashes
> externally and providing some way of associating the seed with these
> external caches so they will still work.
>
> -Rasmus



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/