date:20160817

On 18/08/16 01:02, Daniel Morris wrote:
> both of those are likely more widely used by the
> community than Interbase,

Can you justify that statement!
I'd add that PHP5.2/3 is more widely used that PHP7 ...

And as already said it's not that we don't want to maintain it, it's
that we have no one who is competent enough to maintain it.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-17 Thread Christopher Jones




On 15/08/2016 6:17 PM, Kalle Sommer Nielsen wrote:

Hi Stas

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev :

Hi!

I'd like to propose an RFC to deal with extensions that currently have
no maintainer:

https://wiki.php.net/rfc/umaintained_extensions





pdo_oci
I have heard that maybe Oracle was going to take over this one, but it
seems fairly inactive, maybe this thread can help reach out to them.


Yep.

I've added myself to EXTENSIONS as PDO_OCI maintainer; can you take it
out of the RFC?

Thank you!

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

2016-08-17 Thread Stanislav Malyshev

Hi!

> I think you wrote your JavaScript code to impose certain format for "date",
> "phone", "zip", etc. It's not my JavaScript code, but your JavaScript code
> that defines output of browser to your PHP web apps.

There are a lot of use cases that don't have Javascript (or browser, for
that matter) frontends. Not that it should matter, as browser is not
under your code's control, it's under user's control, and you never know
on the PHP side if such thing as browser exists at all.

> Accept means that allow program to process input data. (continue execution)

Then we disagree here. I strongly object to the notion that the program
should stop execution at any unexpected data. This is only marginally
better than crashing, and is not very helpful behavior. Modern
application is expected to handle data in a more intelligent manner.

> If your JavaScript date picker uses "MMDD" format (date like
> 20160817) for a date, anything other than "MMDD" format is
> attacker tampered inputs.

You keep returning to Javascript. What I am asking you to consider is
that we're not talking about Javascript, we are talking about PHP, and
PHP has no relation to Javascript date picker. Some apps use Javascript
date pickers, true, but there is a whole world of applications that do
nothing of the sort. Javascript does not add much to the picture here.

> It may be considered "valid input" means expected inputs from _legitimate_
> users. Anything other than "valid input" should not be accepted because
> they come from non legitimate users. i.e. attackers.
> 
>  - Broken encoding
>  - CNTRL chars
>  - Bad format ( MMDD is the format for this case )
>  - Too long or short ( Exactly 8 chars is the length for this case )
>  - and so on
> 
> are examples of invalid inputs.

I think this has a smell of blacklisting, which is always almost wrong
approach to dealing with data filtering/validation. Blacklists almost
always lose to whitelists. If you have a whitelist filter that validates
the data, you don't need to worry about chars, lengths and such
separately. However, there's nothing here that requires the whitelist
filter would bring down the app on failure. It should tell the business
logic "this string you gave me is not a valid date" and business logic
should deal with it. There's nothing special here in encodings, control
chars, etc. that I can see that needs any special handling.

> It may increase your work, but you'll get less risks in return.

I don't see how. I can write intelligent code that produces helpful
messages and be the same - in fact, more, see above about whitelisting -
robust than blackbox code that explodes on bad inputs.

> The input validation only reject invalid input.
> 
> If you use plain  for "date", then you should consider any valid
> UTF-8 without CNTRL chars up to 100 char or so, not "MMDD".
> (Assuming UTF-8 is the encoding)

But why? If I just check for MMDD I automatically get all invalid
UTF-8 etc. rejected, without even thinking about it.

> Software design is upto developers. There are many softwares that do
> not follow best practices. Nobody enforce to use the validator as I
> explains. It's okay to me this is used by only users who need. As I
> mentioned, ISO 27000/ISMS requires this kind of validations, not few
> users may need this.

I'm not sure what ISO says there, but I'm pretty sure ISO does not
specify which exactly code you should use to validate your inputs. The
objections are not about validating inputs as a concept, nobody would
object to that, it's to specific model of doing this that you propose -
namely, doing two separate validation passes, doing blacklisting and
bailing out on validation failure. At least I would not do input
validation in this manner.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-17 Thread Daniel Morris

Interbase would be much better existing in PECL, since there is no
interest in supporting it by internals. Couchbase and Cassandra both
exist in PECL and both of those are likely more widely used by the
community than Interbase, and both are also still maintained (with
commits as recently as this month.)

--
Daniel Morris
dan...@honestempire.com

On Thu, 18 Aug 2016, at 12:32 AM, Kalle Sommer Nielsen wrote:
> Hi
> 
> 2016-08-15 7:53 GMT+02:00 Stanislav Malyshev :
> > Please comment and discuss!
> 
> What about adding the following:
> ext/dba
> ext/interbase
> ext/recode
> 
> I tried to look for anything recode, but it seems far gone, although I
> did not do an extensive search for it. I'm unsure about the usage
> though, but I doubt it can be much, considering we got iconv.
> 
> As for DBA, this extension have not really seen any major updates or
> anything since 2009 when the Tokyo Cabinet support was added (PHP
> 5.3), is this still used largely or?
> 
> Interbase have already been discussed a fair bit in this thread, and
> it does not seem Leister is going to contribute despite being the only
> one around interested in this one, at least here on internals@.
> 
> -- 
> regards,
> 
> Kalle Sommer Nielsen
> ka...@php.net
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] orphan extensions cleanup

2016-08-17 Thread Kalle Sommer Nielsen

Hi

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev :
> Please comment and discuss!

What about adding the following:
ext/dba
ext/interbase
ext/recode

I tried to look for anything recode, but it seems far gone, although I
did not do an extensive search for it. I'm unsure about the usage
though, but I doubt it can be much, considering we got iconv.

As for DBA, this extension have not really seen any major updates or
anything since 2009 when the Tokyo Cabinet support was added (PHP
5.3), is this still used largely or?

Interbase have already been discussed a fair bit in this thread, and
it does not seem Leister is going to contribute despite being the only
one around interested in this one, at least here on internals@.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On 17/08/16 21:30, Yasuo Ohgaki wrote:
>> We are on the same book, just coming at this from different ends. It's
>> > that 'my_input_spec_def_for_this_file.php' which is the problem starting
>> > with just where you get the set of rules from and not having a simple
>> > beginner friendly method of adding those rules to a variable. There are
>> > hundreds of legacy examples of how to do a login form, and the vast
>> > majority use styles of programming that start a user down the wrong path
>> > from day one ... so can we agree on something simple and easily
>> > expandable? filter_require_var_array($_POST, $post_spec); could then use
>> > those rules to build the $post_spec array, but why not just use the
>> > rules direct?
> "Direct" means like this?
> 
> $mybool = filter_require_var($_POST['mybool'], FILTER_VALIDATE_BOOLEAN);
> 
> It's possible write code with filter_var()/filter_requrie_var(). It
> requires many lines looks mostly the same.
> 
> Anyway, it seems you have strong opinion for your security model. It's
> okay to adopt design fits your needs and requirements. For example,
> authentication by username & password is weaker than 2 factor
> authentication, but it's still acceptable. DbC is excellent way to
> build secure and fast apps, but adoption is choice of developers.

Actually I have no objection to your array checker. What I am trying to
point out is that POPULATING the array to make your filter work is much
better populated from a 'by variable' storage of the full set of rules
needed to complete ALL validating checks.

MY understanding is that the $_REQUEST array is built from the content
of the post message? This involves building a set of variables to work
with? I am looking at the dump of a current $_REQUEST and rather than
extracting the keys for the array, processing to build your filter rule
array, and applying that against the $_REQUEST array, I would prefer
that the sort of filtering you are talking about happened prior to
creating the variables IN the array ... and one can potentially add the
full validation rules to the variables, in the process.

What we are differing on is just where unusable data can be ignored, and
if you want to kill processing the $_REQUEST array as soon as you detect
corruptions in the data why not do that if the first variable CREATED is
corrupt? No need to load all the rest of the post/get data? On the other
hand one can create all variables and only populate the ones that do
have valid data. This is perhaps where the exception model is simply on
alternate to an error handling model. In my model I can stop processing
the $_REQUEST array if I establish there is an existing record so there
is no need to process any of the rest of the post data. Or at least I
could if the basic variables had the ability to carry out validation
while BUILDING the $_REQUEST array. In exception mode the first
exception kills the process. In error mode we simply decide how to
handle the problem which may then involve checking what attack mechanism
is being used ... or simply say invalid data and reload the the form. If
it was just a problem with one field then that field can be ignored
while the rest can be mirrored back to the form.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Argon2 Password Hash

2016-08-17 Thread Tom Worster

On 8/17/16, 3:48 PM, "Charles R. Portwood II"

wrote:

>Hi everyone,
>
>I've spent the last week and a half playing around with various cost
>factors on different virtual machines and hardware (including compiling
>this down for armv6 and testing on a Pi Zero), and looking over the spec
>a bit more and would like to update the proposal to use the following
>cost factors:
>
>
>memory_cost = 1 MiB
>time_cost = 2
>threads = 2
>
>
>There are no "bad" cost factors for Argon2, but obviously more work is
>better than less. These cost factors provide sufficient work effort
>without exhausting system resources. Argon2 is pretty fast with these
>cost factors even on a Pi Zero, which is the most resource constrained
>system I could get my hands on. In all my testing I wasn't ever able to
>get memory exhaustion to occur just from running argon2 hashing.
>
>I'd like to gather some last feedback and make sure there aren't any
>serious objections to these cost factors (or anything else for that
>matter) before putting this up for a vote. Please let me know your
>thoughts.

Hi Charles,

I trust your judgement in drawing conclusions from these experiments.

Thank you for the work you've put in.

Tom



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

2016-08-17 Thread Pascal MARTIN, AFUP


Le 10/08/2016 à 11:14, Yasuo Ohgaki a écrit :

Hi all,

This is RFC for adding session_create_id() function.


Hi again,

Not that many of us at AFUP discussed about this RFC (maybe it's because 
of the summer and holidays, or it's because not many of us need this?), 
but those who did all agree having such a function provided by PHP will 
be better than trying to implement it ourselves, the day it's actually 
needed -- and it's a single function without much impact or bc-break 
anywhere else.


So, we would be +1.

Thanks again for your work on this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions tofiltermodule

2016-08-17 Thread Christoph M. Becker

On 17.08.2016 at 12:52, Lester Caine wrote:

> On 17/08/16 10:36, Christoph M. Becker wrote:
>> On 17.08.2016 at 10:58, Lester Caine wrote:
>>
 ( and the javascript thing is more a case of upgrading PHP examples to
 use html5 validation by default )
> 
>> And thereby suggesting that HTML5 or JavaScript validation reduces the
>> need to do proper input validation on the PHP side?  No, please.
> 
> SIMPLY to help new users understand how the whole process works. NOT
> helping users with the whole process is what is wrong. And if you look
> at may recent messages you will see that this is just a small part of
> handling inputs. NOT doing something because you don't like it is not
> helping newcomers. Best practice should prevail rather than 'it's not
> PHP so we ignore it'.

Okay, I get your point, and I'm not opposed to adding this information.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][VOTE] Add session_gc() function

2016-08-17 Thread Pascal MARTIN, AFUP


Le 10/08/2016 à 11:30, Yasuo Ohgaki a écrit :

Hi all,

This RFC is to add session_gc() function.


Hi,

We at AFUP would be +1 on this RFC to add a session_gc() function.

Basically: there are some situations were it could be useful and it's a 
quite self-contained change.


Thanks for you work on this!

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

2016-08-17 Thread Yasuo Ohgaki

Hi Lester,

On Wed, Aug 17, 2016 at 5:08 PM, Lester Caine  wrote:
> On 17/08/16 03:59, Yasuo Ohgaki wrote:
>> > require_once('my_exception_error_handler.php');
> Actually load framework ... and that is the first can of worms?
>
>> require_once('my_input_spec_def_for_this_file.php');
> THIS is my sticking point ...
> What it needs to load is the rules for all of fields that were in the
> page build. For simple forms that is fine, but it does not scale. For
> more complex form it has to scan the input array and build a list of
> keys ... why not carry out checks while doing that scan? Makes building
> an array of rules pointless, just use the individual rules ... except we
> do not know where to get them.

Almost all inputs for a request has fixed set of input that is defined by
application specification.

Your example is special case. You can choose whatever method fits
your needs and requirements.

>
>> // Validate general requirement that cannot covered by filter_requrie*()
>> validate_inputs();
>> // These are came from this RFC. Validate inputs.
>> // What's to validate is design decision, but validating them all is the
>> // best way.
>> filter_require_var_array($_GET, $get_spec);
>> filter_require_var_array($_POST, $post_spec);
>> filter_require_var_array($_COOKIE, $cookie_spec);
>> filter_require_var_array($_SERVER, $server_spec);
> I have less of a problem with the STATIC stuff covered here EXCEPT that
> would be handled as part of loading the framework and include checking
> what state of handling the form you ARE at. In my case the session has
> elements of handling multiple page forms.
>
>> session_start(['use_csrf_protection'=>1]);  // There is RFC for this.
>>
>> function check_user_input_error($today) {
>>   if (strtotime($today) != date('Ymd')) {
>> $err_msg[] = 'You have entered invalid date. '. $today;
>>  return $err_msg;
>>   }
>> }
>
> I will not waste time going through your long discussion on handling
> dates it's the bain of my life! Especially when you get given 12/8/2016
> and have no idea if it is August or December! So forms use date pickers

I'm lost. The contract between client and server is "$today must have
'MMDD' format".

> and browser validation. And the "'You have entered invalid date. '.
> $today;" forms part of the set of rules used to build the form. Validate
> that christening date is later than birth date has a suitable error
> message as part of that rule set. Now cross checking those rules at this
> stage is probably necessary but only if some hacker is trying to be
> cleaver? But in my case business rules can be cross checked in the

The design I'm presenting does not handle errors that has to display
errors message to users.

> database ... apps other than PHP  may also be accessing it ( think
> pigging phone apps :( ) ... so the same rules are needed in the database
> business logic. And that is why populating the PHP rules data from the
> database schema makes sense.

It's the same input validation method as Rails. It works mostly, but it
does not sometimes.

Mass Assignment is one example.
(It's the same vulnerability as register_globals=On.
Difference is whether attack target is program variable or database field.
There is mitigation called strong parameters that prevents unwanted
database field updates.)

[CVE-2016-2098] Possible remote code execution vulnerability in Action Pack
https://groups.google.com/forum/#!topic/rubyonrails-security/ly-IH-fxr_Q
(It's "ID" validation oops! "ID" was used w/o validation and resulted
in arbitrary code execution.)

These fatal vulnerabilities could be prevented if Rails adopt the input
validation method described in the RFC.

Validations in model has issues:
 - Security model is based on RDB table definitions. Input data that
are not stored in RDB tends to be used without validation.
 - Validation is performed when data is stored into RDB. Validation
could be too late to be useful.
 - Since there is no validation in controller, it tends to allow
redirection to other systems without parameter validations. (SSRF)
 - Since security model is strongly tied to RDB, validation rule tends
to be weak. e.g. Defines only "require"(=NOT NULL) and don't care the
contents.
 - Model without RDB tends to be weaker/have issues because validation
rules for RDB tables may not be suitable to the task implemented by
the model.

Even though it has issues, validations in model works. However, it
does not work well if you try to validate "all inputs" from outside. For
instance, validating browser request headers and/or environment
variables in ActiveRecord does not make sense.

Rails security model is not optimized for security but for ease of use.
(The DRY - Don't Repeat Yourself) It works well for many apps, so it's
Ok to choose this security model. I'm presenting security optimized
input validation design. Security has tradeoff relation to cost and ease
of use. No wonder that you feel more burden for adopting

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Argon2 Password Hash

2016-08-17 Thread Charles R. Portwood II

On Sat, Aug 6, 2016 at 12:55 PM, Charles R. Portwood II <
charlesportwoo...@erianna.com> wrote:
>
>
> I think there's a bunch of ways we can tweak this. As there's no "bad"
> values for any of these cost factors per the spec, it may just be easy to
> set the costs even lower end user decide if they need to be increased (or
> increase them in core at a later time).
>

Hi everyone,

I've spent the last week and a half playing around with various cost
factors on different virtual machines and hardware (including compiling
this down for armv6 and testing on a Pi Zero), and looking over the spec a
bit more and would like to update the proposal to use the following cost
factors:

memory_cost = 1 MiB
> time_cost = 2
> threads = 2

There are no "bad" cost factors for Argon2, but obviously more work is
better than less. These cost factors provide sufficient work effort without
exhausting system resources. Argon2 is pretty fast with these cost factors
even on a Pi Zero, which is the most resource constrained system I could
get my hands on. In all my testing I wasn't ever able to get memory
exhaustion to occur just from running argon2 hashing.

I'd like to gather some last feedback and make sure there aren't any
serious objections to these cost factors (or anything else for that matter)
before putting this up for a vote. Please let me know your thoughts.

Thanks,
*Charles R. Portwood II*

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

On Wed, Aug 17, 2016 at 7:17 PM, Aaron Piotrowski  wrote:

>
> > On Aug 17, 2016, at 12:02 PM, Marco Pivetta  wrote:
> >
> > That would have been a headache anyway. We saw it coming, and it will be
> fixed on our end, but please don't try to outsmart it.
> > I know that there is good intention on your side, but this is really
> going to just make it an issue.
>
> Looks like this problem is more complicated than I thought. I thought
> prepending the \ would mean little work on your end, but it appears I was
> wrong.
>
> I'm still confused as to what's going on and what the best solution is...
> Currently Doctrine is manually prepending \ to class names. Obviously your
> logic would have to change between 7.0 and 7.1, but then going forward you
> could rely on ReflectionType::__toString() to return a syntax-valid type
> name, rather than modifying it. Or perhaps rather than relying on casting
> to a string and examining the string, Doctrine should be using
> ReflectionNamedType::getName() and ReflectionType::allowsNull() for 7.1 and
> beyond. (Just a suggestion, I'd have to dig into the code to really
> understand what's going on, and I don't have a ton of time to do so at the
> moment.)
>

The problem is that we're not talking about 1 library, but a few (and I'm
only talking about the ones I know of).
Changing behavior is going to cause issues.


> > From the codegen-side (I do write a lot of code generators), having `\`
> prepended in front of stuff makes things just more complex to deal with,
> since I have to strip it and re-introduce it anyway in multiple locations
> in the code, while it should just be attached in the final output-logic bit.
> > Instead, please keep the reflector on-spot: reflecting things, telling
> us what they are. What the code generator does with the definitions is up
> to the code generator after that.
> >
> > We have to adjust the code for `void` and `?` anyway, so this is just
> more changes to keep track of, and it would break existing code.
>
> It sounds like you'd prefer the ? was not prepended to the string as well,
> is that correct? Again it sounds like it would be better to use methods
> other than __toString(). I understand __toString() was the only way to get
> the type name before, but now that this has been fixed perhaps it should be
> avoided in your use-cases.


I think that adding the `?` would be semantically correct, from a reflector
perspective (remember, we are only reflecting: please completely ignore the
idea of using this for codegen, it is a separate domain).

I can't tell you for sure right now, but I will check on Friday.

Libraries that directly affect me personally are doctrine/common,
zendframework/zend-code and ocramius/proxy-manager, so I am only talking
about these 3 for now.
If I remember correctly, in all three a `(string)` cast is being used for
discovering scalar types, although I am not sure.

Can you please poke me at EOD on Friday, so maybe we look at this together?

Cheers,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

> On Aug 17, 2016, at 12:02 PM, Marco Pivetta  wrote:
> 
> That would have been a headache anyway. We saw it coming, and it will be 
> fixed on our end, but please don't try to outsmart it.
> I know that there is good intention on your side, but this is really going to 
> just make it an issue.

Looks like this problem is more complicated than I thought. I thought 
prepending the \ would mean little work on your end, but it appears I was wrong.

I'm still confused as to what's going on and what the best solution is... 
Currently Doctrine is manually prepending \ to class names. Obviously your 
logic would have to change between 7.0 and 7.1, but then going forward you 
could rely on ReflectionType::__toString() to return a syntax-valid type name, 
rather than modifying it. Or perhaps rather than relying on casting to a string 
and examining the string, Doctrine should be using 
ReflectionNamedType::getName() and ReflectionType::allowsNull() for 7.1 and 
beyond. (Just a suggestion, I'd have to dig into the code to really understand 
what's going on, and I don't have a ton of time to do so at the moment.)

> From the codegen-side (I do write a lot of code generators), having `\` 
> prepended in front of stuff makes things just more complex to deal with, 
> since I have to strip it and re-introduce it anyway in multiple locations in 
> the code, while it should just be attached in the final output-logic bit.
> Instead, please keep the reflector on-spot: reflecting things, telling us 
> what they are. What the code generator does with the definitions is up to the 
> code generator after that.
> 
> We have to adjust the code for `void` and `?` anyway, so this is just more 
> changes to keep track of, and it would break existing code.

It sounds like you'd prefer the ? was not prepended to the string as well, is 
that correct? Again it sounds like it would be better to use methods other than 
__toString(). I understand __toString() was the only way to get the type name 
before, but now that this has been fixed perhaps it should be avoided in your 
use-cases.

Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

On Wed, Aug 17, 2016 at 6:55 PM, Aaron Piotrowski  wrote:

>
> > On Aug 17, 2016, at 11:45 AM, Marco Pivetta  wrote:
> >
> > Since scalar types are invalid anyway if prepended with `\`, I see no
> point
> > in producing a string with the `\` in it.
> >
> > The current consumers of `Type` assume no `\` is prepended, and we spent
> an
> > age and a half dealing with `\` being in front of class names in doctrine
> > (and finally got rid of it).
> >
> > This is not being really helpful, as it is.
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius
> >
> > http://ocramius.github.com/
> >
>
> Scalar types do not have a \ prepended. Only class, interface, and trait
> names.
>

Aware.

> Can you show me some of the code in Doctrine that handles this? This issue
> came up because of Doctrine prepending a \ in front of nullable class names
> [1], resulting in `\?Type`, which of course is invalid.
>

This is something to be fixed by introducing support for PHP 7.1 from our
(doctrine/zendframework) side, not from PHP's side by changing existing
behavior (very very very messy).
Doctrine does not yet deal with 7.1, although work started on it, and I'll
likely complete it once we get at last RC phases of 7.1:
https://github.com/doctrine/common/pull/734/files

> Unfortunately I think no matter what is done, nullable types just created
> another headache for you. :-(
>

That would have been a headache anyway. We saw it coming, and it will be
fixed on our end, but please don't try to outsmart it.
I know that there is good intention on your side, but this is really going
to just make it an issue.

>From the codegen-side (I do write a lot of code generators), having `\`
prepended in front of stuff makes things just more complex to deal with,
since I have to strip it and re-introduce it anyway in multiple locations
in the code, while it should just be attached in the final output-logic bit.
Instead, please keep the reflector on-spot: reflecting things, telling us
what they are. What the code generator does with the definitions is up to
the code generator after that.

We have to adjust the code for `void` and `?` anyway, so this is just more
changes to keep track of, and it would break existing code.

P.S.: a lot of confusion between direct/mailing-list responses. Sorry if
this comes through as a new thread, that's not intentional.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

> On Aug 17, 2016, at 11:45 AM, Marco Pivetta  wrote:
> 
> Since scalar types are invalid anyway if prepended with `\`, I see no point
> in producing a string with the `\` in it.
> 
> The current consumers of `Type` assume no `\` is prepended, and we spent an
> age and a half dealing with `\` being in front of class names in doctrine
> (and finally got rid of it).
> 
> This is not being really helpful, as it is.
> 
> Marco Pivetta
> 
> http://twitter.com/Ocramius
> 
> http://ocramius.github.com/
> 

Scalar types do not have a \ prepended. Only class, interface, and trait names.

Can you show me some of the code in Doctrine that handles this? This issue came 
up because of Doctrine prepending a \ in front of nullable class names [1], 
resulting in `\?Type`, which of course is invalid.

Unfortunately I think no matter what is done, nullable types just created 
another headache for you. :-(

Aaron Piotrowski

[1] https://github.com/php/php-src/pull/2068#issuecomment-239983716

(Forgot to CC internals again... ugh)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

Since scalar types are invalid anyway if prepended with `\`, I see no point
in producing a string with the `\` in it.

The current consumers of `Type` assume no `\` is prepended, and we spent an
age and a half dealing with `\` being in front of class names in doctrine
(and finally got rid of it).

This is not being really helpful, as it is.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Wed, Aug 17, 2016 at 6:44 PM, Aaron Piotrowski  wrote:

> Marco,
>
> > On Aug 17, 2016, at 11:22 AM, Marco Pivetta > wrote:
> >
> > Sorry, I have to object here: this is quite a BC break for Zend\Code,
> specifically. We will have to re-adjust the code generators to adapt to the
> newly introduced prepended `\`.
> >
> > In addition to that, there is no need for `\` to be prepended to a type
> string, since inside string scope, we are always dealing with the base
> namespace.
> >
> > Seems unnecessary and causes a lot of headaches, instead of actually
> simplifying things.
> >
> > Marco Pivetta
> >
> > http://twitter.com/Ocramius 
> >
> > http://ocramius.github.com/ 
> >
>
>
> Adjustments will be necessary in Zend\Code no matter what because of
> nullable types. If a type is nullable, ReflectionType::__toString() will
> return "?\Type\Name" or without the changes I committed it would return
> "?Type\Name".
>
> If you need the type name without the leading ? or \, use
> ReflectionNamedType::getName().
>
> It would be nice to have no BC breaks, but right now I'm not seeing a way
> of handling nullable types in ReflectionType::__toString() without some
> sort of BC break.
>
> Aaron Piotrowski
>
>

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

Marco,

> On Aug 17, 2016, at 11:22 AM, Marco Pivetta  > wrote:
> 
> Sorry, I have to object here: this is quite a BC break for Zend\Code, 
> specifically. We will have to re-adjust the code generators to adapt to the 
> newly introduced prepended `\`.
> 
> In addition to that, there is no need for `\` to be prepended to a type 
> string, since inside string scope, we are always dealing with the base 
> namespace.
> 
> Seems unnecessary and causes a lot of headaches, instead of actually 
> simplifying things.
> 
> Marco Pivetta 
> 
> http://twitter.com/Ocramius   
> 
> http://ocramius.github.com/ 
> 

Adjustments will be necessary in Zend\Code no matter what because of nullable 
types. If a type is nullable, ReflectionType::__toString() will return 
"?\Type\Name" or without the changes I committed it would return "?Type\Name".

If you need the type name without the leading ? or \, use 
ReflectionNamedType::getName().

It would be nice to have no BC breaks, but right now I'm not seeing a way of 
handling nullable types in ReflectionType::__toString() without some sort of BC 
break.

Aaron Piotrowski

Re: [PHP-DEV] ReflectionType::__toString() prepending \ to class names

Sorry, I have to object here: this is quite a BC break for Zend\Code,
specifically. We will have to re-adjust the code generators to adapt to the
newly introduced prepended `\`.

In addition to that, there is no need for `\` to be prepended to a type
string, since inside string scope, we are always dealing with the base
namespace.

Seems unnecessary and causes a lot of headaches, instead of actually
simplifying things.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Wed, Aug 17, 2016 at 6:18 PM, Aaron Piotrowski  wrote:

> Hi all,
>
> I recently made some changes [1] to ReflectionType::__toString() that
> prepends a leading \ to class names. These changes follow from the
> discussion on ReflectionType improvements [2, 3] and the discussion on my
> PR to implement some of the RFC [4].
>
> A \ should be prepended to class names returned from
> ReflectionType::__toString() so the output of this method can be used when
> generating code within a namespace. Currently, several libs such as
> Doctrine manually prepend a \ when generating code. Nullable types will
> complicate this, since a ? is prepended to the type name, requiring a \ to
> instead be inserted as the second character. The changes I made will
> alleviate the need for libs to manipulate the string returned from
> ReflectionType::__toString() when generating code. This will become more
> important if more complex types are introduced, such as callable prototypes.
>
> If anyone has objections to these changes, please let me know.
>
> Thanks!
>
> Aaron Piotrowski
>
> [1] http://git.php.net/?p=php-src.git;a=commitdiff;h=
> 20fdd47921f423728b409fd0ae0106dab9c34573
> [2] http://news.php.net/php.internals/94452
> [3] https://wiki.php.net/rfc/reflectiontypeimprovements
> [4] https://github.com/php/php-src/pull/2068#issuecomment-240071841
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] ReflectionType::__toString() prepending \ to class names

Hi all,

I recently made some changes [1] to ReflectionType::__toString() that prepends 
a leading \ to class names. These changes follow from the discussion on 
ReflectionType improvements [2, 3] and the discussion on my PR to implement 
some of the RFC [4].

A \ should be prepended to class names returned from 
ReflectionType::__toString() so the output of this method can be used when 
generating code within a namespace. Currently, several libs such as Doctrine 
manually prepend a \ when generating code. Nullable types will complicate this, 
since a ? is prepended to the type name, requiring a \ to instead be inserted 
as the second character. The changes I made will alleviate the need for libs to 
manipulate the string returned from ReflectionType::__toString() when 
generating code. This will become more important if more complex types are 
introduced, such as callable prototypes.

If anyone has objections to these changes, please let me know.

Thanks!

Aaron Piotrowski

[1] 
http://git.php.net/?p=php-src.git;a=commitdiff;h=20fdd47921f423728b409fd0ae0106dab9c34573
[2] http://news.php.net/php.internals/94452
[3] https://wiki.php.net/rfc/reflectiontypeimprovements
[4] https://github.com/php/php-src/pull/2068#issuecomment-240071841
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-08-17

2016-08-17 Thread lp_benchmark_robot

Results for project PHP master, build date 2016-08-17 06:22:41+03:00
commit: cf3a798
previous commit:befca6a
revision date:  2016-08-17 01:44:58+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.17%  0.60%  6.62%  
  6.36%
:-)   Drupal 7.36 cgi -T1  0.14%  1.05% -0.11%  
  4.44%
:-|   MediaWiki 1.23.9 cgi -T5000  0.14%  0.48%  0.10%  
  3.72%
:-|   bench.php cgi -T100  0.00%  0.46% 32.46%  
 -1.48%
:-)  micro_bench.php cgi -T10  0.10%  2.53% 14.54%  
 -0.11%
:-)  mandelbrot.php cgi -T100  0.02%  1.07% 31.65%  
 -7.34%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/good-benchmark-results-for-php-master-2016-08-17/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

2016-08-17 Thread Yasuo Ohgaki

Hi Stas,

On Wed, Aug 17, 2016 at 5:33 PM, Stanislav Malyshev <smalys...@gmail.com> wrote:
>> Let's say your app validate user written/chosen "Date" on client side by
>> JavaScript. Then browser must send whatever "Date" format you impose
>> to client. It may be "MMDD", for example.
>
> I'm not sure what Javascript has to do with it. Many apps don't have any
> client-side and have little to do with Javascript. Assuming that whole
> world is browser applications running Javascript (controlled by you)
> would be a big mistake.

I think you wrote your JavaScript code to impose certain format for "date",
"phone", "zip", etc. It's not my JavaScript code, but your JavaScript code
that defines output of browser to your PHP web apps.

>
>> Then programer should not accept "Date" format other than "MMDD"
>> because other format is invalid. Accepting format other than "MMDD"
>> does only bad and increase risks of program malfunctioning. i.e. All kinds
>> of injections like JavaScript, SQL, Null char, Newline, etc.
>
> What you mean by "accept" here? I think you are under impression (please

Accept means that allow program to process input data. (continue execution)

> correct me if I'm wrong) that there are only two ways for application to
> work - either treating all inputs equally, or bailing out immediately
> when incorrect input is detected. However, this is not the case, there
> are many other ways for application to handle the situation of invalid
> input - while knowing it is invalid - and exact manner of this handling
> is application-dependent.

If your JavaScript date picker uses "MMDD" format (date like
20160817) for a date, anything other than "MMDD" format is
attacker tampered inputs.

It may be considered "valid input" means expected inputs from _legitimate_
users. Anything other than "valid input" should not be accepted because
they come from non legitimate users. i.e. attackers.

 - Broken encoding
 - CNTRL chars
 - Bad format ( MMDD is the format for this case )
 - Too long or short ( Exactly 8 chars is the length for this case )
 - and so on

are examples of invalid inputs.

>
>> "Input validation" should reject all of them and does not have to inform 
>> users
>> (attackers) to "there is invalid input". If you need to tell  legitimate 
>> users
>
> I think we disagree here. I think not doing this makes my work as a
> developer much much harder.

It may increase your work, but you'll get less risks in return.
It's all about avoiding/mitigating possible risks with additional costs.

I know you've fixed many vulnerabilities in PHP. What's the best way to
avoid broken char encoding attacks in some libraries? Validating string
char encoding is the best way as nobody can guarantee correct behavior
with broken char encoding in a system.

i.e. There are many codes that misbehave with broken encodings.
Software is changed continuously. Even if one had 100% broken
encoding attack free code at certain point, it could be vulnerable
due to software version ups.

>
>> "There is invalid input", then it should be treated by "Business logic", not 
>> by
>> "Input validation".
>
> Wait, input validation happens before business logic has a chance to
> run, so if input validation bails, how business logic can treat anything?

The input validation only reject invalid input.

If you use plain  for "date", then you should consider any valid
UTF-8 without CNTRL chars up to 100 char or so, not "MMDD".
(Assuming UTF-8 is the encoding)

>> "User name" and "Password" shouldn't have CNTRL chars or invalid char
>> encoding. Even when fields are plain , there shouldn't be 500 chars
>> long inputs for them.
>
> So your proposal seems to be having two input checking procedures
> instead of one. I don't think people would find it very useful to have
> two separate input checking procedures.

If you blindly follow best practice that "Control/validate all inputs", then
previously mentioned inputs like browser request headers

 - Invalid REFERER contains Illegal/CTNRL chars and/or too many chars.
 - Invalid ACCEPT-CHARSET contains Illegal/CNTRL chars and/or too many chars.
 - Invalid ACCEPT-ENCODING contains Illegal/CNTRL chars and/or too many chars.
 - Invalid ACCEPT-LANGUAGE contains Illegal/CNTRL chars and/or too many chars.
 - and so on.

must be validated. I don't think it's a business logic job since it's
unrelated to most business logic.

Attackers are trying to tamper via any inputs that software accepts.
Therefore, developers are needed to try to reduce poss

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filtermodule

On 17/08/16 10:36, Christoph M. Becker wrote:
> On 17.08.2016 at 10:58, Lester Caine wrote:
> 
>> > ( and the javascript thing is more a case of upgrading PHP examples to
>> > use html5 validation by default )

> And thereby suggesting that HTML5 or JavaScript validation reduces the
> need to do proper input validation on the PHP side?  No, please.

SIMPLY to help new users understand how the whole process works. NOT
helping users with the whole process is what is wrong. And if you look
at may recent messages you will see that this is just a small part of
handling inputs. NOT doing something because you don't like it is not
helping newcomers. Best practice should prevail rather than 'it's not
PHP so we ignore it'.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filtermodule

2016-08-17 Thread Christoph M. Becker

On 17.08.2016 at 10:58, Lester Caine wrote:

> ( and the javascript thing is more a case of upgrading PHP examples to
> use html5 validation by default )

And thereby suggesting that HTML5 or JavaScript validation reduces the
need to do proper input validation on the PHP side?  No, please.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

2016-08-17 Thread Tony Marston

"Yasuo Ohgaki" wrote in message
news:caga2bxzjgggpjsvxqmdjmqvnptbucahazbwjrtbipsb-boh...@mail.gmail.com...

Hi Tony,

Allow me to top post.

"The input validation" is not for legitimate users, but for attackers.
You shouldn't help attackers by explaining what/how wrong in attackers'
inputs.

If your RFC is about preventing attacks then it should be labelled as such.
Input validation is a totally separate issue.

--
Tony Marston

I've added discussion "Input validation and User input mistake
handling difference"
https://wiki.php.net/rfc/add_validate_functions_to_filter#input_validation_and_user_input_mistake_handling_difference

Please refer to the section for distinction.

BTW, the input validation that I'm proposing here is
required/recommended feature by ISO 27000/ISMS. Why shouldn't PHP
provide features that is needed to implement ISO 27000/ISMS
requirements?

On Mon, Aug 15, 2016 at 8:00 PM, Tony Marston
wrote:

"Dan Ackroyd" wrote in message
news:ca+kxmuriobqpmtekqnyv8rx0gkclryixi--y5tcyukdqpt7...@mail.gmail.com...

Hi Yasuo,

On 15 August 2016 at 01:53, Yasuo Ohgaki wrote:

One more usual request.
Please describe reason(s) why you object proposal.

I'm not entirely sure why you ask for reasons when people vote no. The
reasons are almost always the same as the reasons given before the
voting starts.

But for posterity:

i) Validation error messages need to specify what is wrong.which
is bespoke to the application. Which is a reason why validation code
belongs in userland.

I agree 100%

ii) Validation error message need to be in the correct language for an
application. It is not a good approach for people to be trying to
match strings emitted by internal code and trying to convert them to
the correct language.

I agree 100%

iii) The argument that it needs to be fast could be applied to
anything and everything, and so is bogus. The RFC doesn't even show
that userland implementations are slow enought to be a concern.

iv) The RFC makes an assumption that programs should exit when
validation

fails.

"Input data validation should accept only valid and possible inputs.
If not, reject it and terminate program."

I DISagree 100%. Validation errors should NEVER terminate the program,
they

should continue by displaying all the error messages to the user so that
he/she can correct his/her mistake and try the operation again.

and the code example:

catch (FilterValidateException $e) {
var_dump($e->getMessage());
die('Invalid input detected!'); // Should terminate execution when
input validation fails
}

This assumption is bogus.

Any program that accepts data from users should provide useful error
messages when the data is wrong with someting as simple as a string
being too long.

I agree 100%

v) I don't like the current filter functions, and recommend people
avoid using them. Adding to them with an even harder to use API is the
wrong way to go.

I agree 100%

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On 17/08/16 09:33, Stanislav Malyshev wrote:
>> "Input validation" should reject all of them and does not have to inform 
>> users
>> > (attackers) to "there is invalid input". If you need to tell  legitimate 
>> > users

> I think we disagree here. I think not doing this makes my work as a
> developer much much harder.

I'm with you on this Stanislav ... we need to know what failed in order
to decide what to do about it. While simply crashing out was acceptable
15 years ago, nowadays knowing what attackers are after can be important?

( and the javascript thing is more a case of upgrading PHP examples to
use html5 validation by default )

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On 17/08/16 00:43, Yasuo Ohgaki wrote:
> Allow me to top post.
> 
> "The input validation" is not for legitimate users, but for attackers.
> You shouldn't help attackers by explaining what/how wrong in attackers' 
> inputs.

What is expected as 'post' data input is defined when building the page.
That some people will intercept the page and try to use it to inject
'invalid' data in an attempt to perhaps gain access to data is a
separate problem, but still part of the validation process. One of the
hacks I had to deal with recently was simply an xss hole because nobody
filtered or trimmed the username. So you could just type what you
wanted. Simply add a suitable pattern to the html5 validation and the
casual hacker is averted ... but how many PHP examples actually use html5?

Of cause someone can build their own result set and bypass the browser
validation. Which is where some cleaver use of javascript might help to
add a security check to the submit packet. Outside PHP, but still part
of the overall picture. In any case once the get/post array is in PHP
there is a need to recheck everything once again and while the average
user may not happy simply to bounce the page if the username field now
has an invalid imput, other systems will want to log the attempt and
perhaps capture any source information. White screen crashes because
someone has broken the data can be difficult to unravel especially when
it's some consented effort to get in ... in my case someone trying every
possible Mysql hack against firebird :( So I end up with extra code to
filter the attack attempt and that tends to have to be at the variable
level.

It can be useful to give feedback simply to get them to give up without
an explanation why. Simply crashing the page means they try the next
option until they do get a response ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

2016-08-17 Thread Stanislav Malyshev

Hi!

> Let's say your app validate user written/chosen "Date" on client side by
> JavaScript. Then browser must send whatever "Date" format you impose
> to client. It may be "MMDD", for example.

I'm not sure what Javascript has to do with it. Many apps don't have any
client-side and have little to do with Javascript. Assuming that whole
world is browser applications running Javascript (controlled by you)
would be a big mistake.

> Then programer should not accept "Date" format other than "MMDD"
> because other format is invalid. Accepting format other than "MMDD"
> does only bad and increase risks of program malfunctioning. i.e. All kinds
> of injections like JavaScript, SQL, Null char, Newline, etc.

What you mean by "accept" here? I think you are under impression (please
correct me if I'm wrong) that there are only two ways for application to
work - either treating all inputs equally, or bailing out immediately
when incorrect input is detected. However, this is not the case, there
are many other ways for application to handle the situation of invalid
input - while knowing it is invalid - and exact manner of this handling
is application-dependent.

> "Input validation" should reject all of them and does not have to inform users
> (attackers) to "there is invalid input". If you need to tell  legitimate users

I think we disagree here. I think not doing this makes my work as a
developer much much harder.

> "There is invalid input", then it should be treated by "Business logic", not 
> by
> "Input validation".

Wait, input validation happens before business logic has a chance to
run, so if input validation bails, how business logic can treat anything?

> "User name" and "Password" shouldn't have CNTRL chars or invalid char
> encoding. Even when fields are plain , there shouldn't be 500 chars
> long inputs for them.

So your proposal seems to be having two input checking procedures
instead of one. I don't think people would find it very useful to have
two separate input checking procedures.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module