Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86075
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.180 as permitted sender)
Message-ID: <5541D0F8.8020907@gmail.com>
Date: Wed, 29 Apr 2015 23:51:36 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: Ryan Pallas <derokorian@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com> <55401F31.9030703@gmail.com> <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com> <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com> <55416849.9010808@gmail.com> <CAGa2bXbkCx2Nqb9YBut3id4N=nhjLBGPN8Ucrx7R6mRnGjB2og@mail.gmail.com> <5541753D.5050908@gmail.com> <CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com> <55419C0C.7020207@gmail.com> <CAGa2bXaPAwFs=2=wHAE615dhyFO_5sUnKV4X2cMVFJM9xoG1wg@mail.gmail.com> <5541C0E0.2080006@gmail.com> <CAGa2bXYf+ZUiV6m47aUGsTc4=cZjNZWN_cFGcw4SXB2MJJGYnA@mail.gmail.com>
In-Reply-To: <CAGa2bXYf+ZUiV6m47aUGsTc4=cZjNZWN_cFGcw4SXB2MJJGYnA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Unfortunately, not all users does this and new PHP type hint opens new hole
> that security researchers and attackers are interested in.

I am sorry, but you still brought no proof at all that there are any
security implications. Without such proof, these claims are baseless, so
I intend to ignore them from now until such time as some proof would be
provided, and advise others to do the same.

> I prefer relaxed int/float type hint a lot, but "numeric" can be
> alternative.

No, it can't, because it's not a type, it's string regex check, and we
should not mix those with types.

> It's much easier users to advocate "Use numeric type hint for database
> record ID/etc", rather than "Use string type hint for database _and_
> validate
> it's content by yourself".  

The latter is the right thing to do (well, except for the part where
string type is not really necessary unless you expect to get something
that can't be made string, in which case your code is very messed up by
that point).

> PHP were weakly typed and too strict type hint creates issue. Weakening
> a bit does not harm any, narrowing window to attack. If user needs native 

There's no attack, and it does harm the design of the language by mixing
types with unrelated string regex checks.

> int/float strictly, they should/can use "strict" mode also. 
> 
> Do you see issues with relaxing?

Yes, lots of them.

-- 
Stas Malyshev
smalyshev@gmail.com