Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86061
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbYDAzsqA2PqqngtNTpjN2Oq9-q4BNRjxtU85LJ+WMExg@mail.gmail.com>
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>
	<554176D6.2030007@gmx.de>
	<CAGa2bXaPjvkFYtkhRM1JisSvxgR0v8adkD_P_zkUng4xfBWFHg@mail.gmail.com>
	<55418CBE.6050609@gmail.com>
	<CAGa2bXZAY_9qx9D+K11ApJH9DKzTvxze+=E5=rVhQj_OaGfxGQ@mail.gmail.com>
	<CAGa2bXbYDAzsqA2PqqngtNTpjN2Oq9-q4BNRjxtU85LJ+WMExg@mail.gmail.com>
Date: Wed, 29 Apr 2015 22:29:59 -0600
Message-ID: <CAObuZdspHZwj0370z3+_iKBcpE2Ki-HrFrS9A+BNBw=d3GAcjg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113612bc6bb7220514e98c19
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: derokorian@gmail.com (Ryan Pallas)

--001a113612bc6bb7220514e98c19
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Rowan,
>
> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> >
> >>  A fatal error wouldn't constitute a DoS vulnerability, would it?
> >>>>
> >>>>  Attacker may inject huge ID value and/or they may simply access
> >>> web sites to reach 2 billion limit, for example.
> >>>
> >>
> >> That's not a DoS vector unless you've also done something else wrong,
> >> it's just an embarassing error like many others. A lot of the time, the
> DB
> >> will overflow first anyway, because an SQL "int" is signed 32-bit. Hell,
> >> YouTube had a 32-bit int for number of views until Gangnam Style
> overflowed
> >> it!
> >>
> >
> > Not really. Primary key is out of user control almost always. However,
> > suppose code allows to specify foreign key and code assumes that non
> > existing foreign key results in search query failure.
> >
> > Current PHP: Search query failure.
> > New PHP type hint: Fatal error because foreign key is out of PHP int
> range.
>

How is this different than other languages with type hint? For example,
Java or C# - if you type hint int you are limited to 32bit. These languages
have long and bigint respectively to support 64bit, but type hinting int
means you cannot have arbitrarily large numbers.

To me it sounds like you're trying to solve an application problem but
suggesting a change to the language.

>
> > If user are using type hints everywhere, it may be limited to attackers
> > seeing fatal errors. If not, attacker can succeed system wide DoS attack
> by
> > simple operation.
> >
>
> I should have mentioned that I'm supposing DBMS like SQLite here.
> As we know, SQLite column accepts any value including value beyond 64 bit
> int.
>
https://www.sqlite.org/datatype3.html
> (Those who don't now "Type Affinity", please read the section)
>
> From your link " The value is a signed integer, stored in 1, 2, 3, 4, 6,
or 8 bytes depending on the magnitude of the value." And take a look at
http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/ where
numbers larger than the max are converted to real on storage sometimes,
depending on the affinity of the storage type chosen but not on math.

SQLite is the most used RDBMS in the world.
>
I would love to see some empirical data that supports this claim.


> MySQL supports unsigned 64 bit integer also, BTW.
>


>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--001a113612bc6bb7220514e98c19--