Hi David,
On Fri, May 15, 2015 at 2:12 PM, David Muir davidkm...@gmail.com wrote:
I still don’t see how you can put the blame for the unhanded exception on
type hints. The problem you’re describing is not new and exists today with
libraries using code like this:
function foo($int) {
On 14 May 2015, at 9:27 pm, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Arvids,
On Mon, May 11, 2015 at 8:01 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Hello, I have read through your blog post, and I agreed on the issue
earlier, nut I have a question that bugs me for a while:
On Wed, Apr 29, 2015 at 11:40 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life a pain for regular or
better programmers while only adding mild speed bumps to those
On Wed, Apr 29, 2015 at 11:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Arvids,
On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life
On Wed, Apr 29, 2015 at 11:47 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Walter,
On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker walt...@gmail.com wrote:
And that is relevant how? How many Android phone run PHP applications?
Search web for IoT devices that can run PHP.
Regards,
--
Hi Arvids,
On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life a pain for regular or
better programmers while only adding mild speed bumps
On Thu, Apr 30, 2015 at 12:06 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Walter,
On Thu, Apr 30, 2015 at 3:54 PM, Walter Parker walt...@gmail.com wrote:
You didn't answer the question: why should we care? Is there enough of
user base now to care? IOT might be able to run PHP, but how
Hi Stas,
On Thu, Apr 30, 2015 at 2:42 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
int Cast is bad. Incorrect int type hint worse as it could trigger
DoS.
I do not see any potential for DoS here. Trying to assign security
implications so it looks like disagreeing with you jeopardizes
Hi Walter,
On Thu, Apr 30, 2015 at 3:12 PM, Walter Parker walt...@gmail.com wrote:
And that is relevant how? How many Android phone run PHP applications?
Search web for IoT devices that can run PHP.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Hi Walter,
On Thu, Apr 30, 2015 at 3:54 PM, Walter Parker walt...@gmail.com wrote:
You didn't answer the question: why should we care? Is there enough of
user base now to care? IOT might be able to run PHP, but how many actually
do? And of the ones that do, is automatically half fixing the
Stop trying to fix clever idiots from shooting themselves in the foot. The
standard result from these actions is to make life a pain for regular or
better programmers while only adding mild speed bumps to those clever
idiots.
Things like a numeric type will only encourage the clever idiots
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
On 30/04/15 08:42, Walter Parker wrote:
I thing using string type hints are are easier to advocate (and I think
they are the correct type if you need to be 32/64 indepentent).
Otherwise, a numeric type doesn't fix the problem. It hides it. It is a
short term that doesn't scale properly.
Use
Hi Yasuo,
Am 30.04.2015 um 07:26 schrieb Yasuo Ohgaki:
int Cast is bad. Incorrect int type hint worse as it could trigger DoS.
could you please stop arguing with Denial of Service for this
behavior? Using a security related term that has nothing to do with the
actual problem is irritating.
This numeric type is a type of int or float. There is a formal name
for such types: union types. Some languages have syntax for union
types that would look like this: int | float. I have a draft RFC for
this subject: https://wiki.php.net/rfc/union_types. Union types would
be useful for other
On Thu, Apr 30, 2015 at 7:35 AM, Levi Morrison le...@php.net wrote:
This numeric type is a type of int or float. There is a formal name
for such types: union types. Some languages have syntax for union
types that would look like this: int | float. I have a draft RFC for
this subject:
On Wed, Apr 29, 2015 at 10:42 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
int Cast is bad. Incorrect int type hint worse as it could trigger
DoS.
I do not see any potential for DoS here. Trying to assign security
implications so it looks like disagreeing with you jeopardizes
On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Ryan,
On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote:
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
http://3v4l.org/6J0bZ
I don't
Hi Stas and Ryan,
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com wrote:
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
This is exactly
Hi Francois,
On Wed, Apr 29, 2015 at 7:03 PM, François Laupretre franc...@php.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
This has been a big issue that I have ran into many times in the past for
large framework projects, instead of building it out with strict types
like: int, float, string, exc... It makes more sense to allow a user to
define a psudo-type themselves which PHP will pass the arguments into to be
Hi Christoph,
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com
wrote:
I agree with Stanislav here, if you want to accept any type of number,
its
easy enough to add your own checking to do that
Yasuo Ohgaki wrote:
On Wed, Apr 29, 2015 at 9:33 AM, Ryan Pallas derokor...@gmail.com wrote:
I agree with Stanislav here, if you want to accept any type of number, its
easy enough to add your own checking to do that with the wonderful
is_numeric. And for simplicity, make an invalidArgument
Hi Francois,
On Thu, Apr 30, 2015 at 6:23 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Allowing any forms of int/float as string(and GMP) for weak mode int/float
type hint
would be alternative resolution for this issue. I think it's better than
numeric type
hint.
It seems current
Hi!
The objective to have type hint is to remove such checks by users,
isn't it?
No, not really. The objective is to ensure type of the parameter. If you
checks are not limited to types, then typing is not going to help, and I
don't think inventing special built-in type for each narrow use
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
PHP types are not machine native types. But yes, it forces PHP type -
that's why it is *type* check.
Type hint is better to stay as hint under weak mode. IMO.
Type hints have never been
Hi Yasuo,
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn. It's too late for PHP 7.0 to re-open it,
but it might be reasonable to to so for
Hi Christoph,
On Thu, Apr 30, 2015 at 7:10 AM, Christoph Becker cmbecke...@gmx.de wrote:
Yasuo Ohgaki wrote:
On Thu, Apr 30, 2015 at 6:27 AM, Christoph Becker cmbecke...@gmx.de
wrote:
A solution for this issue has been proposed by the Big Integer Support
RFC which has been withdrawn.
Hi Stas,
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
The objective to have type hint is to remove such checks by users,
isn't it?
No, not really. The objective is to ensure type of the parameter. If you
checks are not limited to types, then typing is not
Hi Nathan,
On Thu, Apr 30, 2015 at 6:41 AM, Nathan Bruer nathanbr...@gmail.com wrote:
This has been a big issue that I have ran into many times in the past for
large framework projects, instead of building it out with strict types
like: int, float, string, exc... It makes more sense to allow
Hi!
If you need to force to map value to PHP type, you have strict mode.
Weak
mode is just too strict currently even if PHP handled int/float/string as
integer/float including invalid values traditionally.
That is what was decided by votes - to make type conversions fail on
values that can
Hi Christoph,
On Thu, Apr 30, 2015 at 9:27 AM, Christoph Becker cmbecke...@gmx.de wrote:
On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
PHP types are not machine native types. But yes, it forces PHP type -
that's why it is *type* check.
Type hint
On 30/04/2015 02:24, Yasuo Ohgaki wrote:
Type hints have never been hints. The wording is a misnomer. Try to
pass an int to a parameter declared as array, for instance.
I understand how it worked and how it will.
hint sounds a little misleading. Since we named it already, we may follow
the
Hi Rowan,
On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 30/04/2015 02:24, Yasuo Ohgaki wrote:
Type hints have never been hints. The wording is a misnomer. Try to
pass an int to a parameter declared as array, for instance.
I understand how it worked
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int range.
There may be some confusion; NikiC is still doing some work to tidy up
the EngineExceptions. When that is finished
Hi Stas,
On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
If you need to force to map value to PHP type, you have strict mode.
Weak
mode is just too strict currently even if PHP handled int/float/string as
integer/float including invalid values
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@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
On Wed, Apr 29, 2015 at 7:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@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
Hi!
How many of us are expected that
mydb_find_by_id(INT_MAX+1);
Note: INT_MAX+1 is pseudo integer string value.
fails with fatal error? I guess it's not many.
I'm not sure what is the meaning of INT_MAX+1 is pseudo integer string
value - if it fits the integer, it's the integer, if it's
Hi Stas,
On Thu, Apr 30, 2015 at 12:05 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
How many of us are expected that
mydb_find_by_id(INT_MAX+1);
Note: INT_MAX+1 is pseudo integer string value.
fails with fatal error? I guess it's not many.
I'm not sure what is the meaning of
Hi!
int Cast is bad. Incorrect int type hint worse as it could trigger DoS.
I do not see any potential for DoS here. Trying to assign security
implications so it looks like disagreeing with you jeopardizes security
is not a good idea. If your code accepts non-numeric data and puts it to
Ryan,
On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas derokor...@gmail.com wrote:
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@ohgaki.net
wrote:
A fatal error wouldn't constitute a DoS
On Wed, Apr 29, 2015 at 9:33 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Walter,
On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote:
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
On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Rowan,
On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki yohg...@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
Hi Walter,
On Thu, Apr 30, 2015 at 11:52 AM, Walter Parker walt...@gmail.com wrote:
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
Dan,
On Thu, Apr 30, 2015 at 12:02 PM, Dan Ackroyd dan...@basereality.com
wrote:
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int
range.
There may be some confusion;
Hi all,
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
http://3v4l.org/6J0bZ
There are cases that programmer want/need to handle any numeric values.
e.g. JSON
On Tue, Apr 28, 2015 at 6:00 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
This is exactly what's
Hi!
External data can have any form of numbers.
Current PHP can handle them as string. However PHP7's type hint cannot
handle numeric data well because it only has int and float hints.
This is exactly what's wrong with strict typing in PHP. However, if you
use real numeric string and do not
50 matches
Mail list logo