Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <90.51.36656.0C0A1B75@pb1.pair.com>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXadVagTwBzEym9PZROmXu3SKxg=huCAQNK3k1-jZeG_pg@mail.gmail.com>
 <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
 <CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com> <90.51.36656.0C0A1B75@pb1.pair.com>
Date: Wed, 17 Aug 2016 09:01:46 +0900
Message-ID: <CAGa2bXYx1Gs7AbYiwV3Knw8JTdC-zUbg+C99-8vmyVZzx+KQ7w@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

To those who voted "no" for this,

On Mon, Aug 15, 2016 at 8:00 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Dan Ackroyd"  wrote in message
> news:CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com...
>>
>>
>> Hi Yasuo,
>>
>> On 15 August 2016 at 01:53, Yasuo Ohgaki <yohgaki@ohgaki.net> 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%
>
>
> --
> Tony Marston


Could you explain why or express "same opinion here"?

IMHO, this opinion is based on misunderstanding of secure coding and
software security methodology. However, either way is helpful.

There are many that seem "the input validation should be implemented
by userland fully". If this is true, I'm going to propose "Filter
module" deprecation next. It's better not to have misleading and/or
half implemented module for security purpose.

Thank you!

--
Yasuo Ohgaki
yohgaki@ohgaki.net