Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 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 19:52:53 -0700
Message-ID: <CAMPTd_DhriS6JdCdVWfd8o+o1Dc_UC+AR=nASSoVu+trzLJn_w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493d123491ad0514e831b1
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: walterp@gmail.com (Walter Parker)

--089e01493d123491ad0514e831b1
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 7: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.
> >
> > 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)
>
> SQLite is the most used RDBMS in the world.
>
> MySQL supports unsigned 64 bit integer also, BTW.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

Are you asking to have both the 32 and 64 bit versions of PHP fully map to
the type system in SQLite? The type system in SQLite appears to have been
setup to map to programming language that lots of types (modern C, C++,
maybe Java) rather than PHP.

I think you might have an easier time fixing the SQLite adaptor for PHP
than making both 32 and 64 bit PHP map to the type structure for SQLite
completely transparently with full type defs.


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--089e01493d123491ad0514e831b1--