Hi all, On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > This RFC is to add functions that are suitable for input validations > for secure coding. IMHO, these additions are mandatory for PHP. > > https://wiki.php.net/rfc/add_validate_functions_to_filter > Vote ends 2016/08/22 23:59:59 UTC > > I don't mind suspend vote and continue discussion if there is issue. > It's rather long RFC. Thank you for reading and voting!
Thank you for voting! The RFC is declined 1 vs 13 A bit surprised this result. I requested the reason of objection, but many of them does not disclose why. https://wiki.php.net/rfc/add_validate_functions_to_filter#proposed_voting_choices bwoebi (bwoebi) colinodell (colinodell) danack (danack) derick (derick) diegopires (diegopires) guilhermeblanco (guilhermeblanco) kguest (kguest) levim (levim) lstrojny (lstrojny) marcio (marcio) nikic (nikic) ocramius (ocramius) peehaa (peehaa) santiagolizardo (santiagolizardo) I would like to summarize objection points during discussion. I assume above of us voted no for these reasons. 0. Input data validation cannot be done because client can be anything. 1. Input data validation should show what's wrong, not exception. 2. Input data validation error and input mistake error should be treated by the same code to remove code redundancy. 3. Current filter module is good enough. IMO. These are clearly wrong reasons of objection. 0. Almost all input data can be validated because of - Web standards. e.g. Almost all form input must be "valid string". - Client side validation. e.g. JS, HTML5. - Many parameters are set by program and shouldn't be changed. e.g. Select, radio, hidden, database record ID. 1. Showing what's wrong in input validation is _ANTI_ practice of security. - Developers should _NOT_ show error details unless it has to, otherwise it helps attackers to tamper system. - "You have broken encoding", "You have unallowed CNTRL char", etc, are the same as "You have entered wrong user name", "You have entered wrong password", "You have entered too long password", etc. 2. This is not reasonable choice for large applications that have higher security requirements. - Strict input validation should check all inputs including request headers and cookies. Checking these in business logic makes things messy and complicated, hence easy to make mistakes. 3. Current filter module does not work for strict validations. - I don't repeat. It just does not work well for strict validation. (NOTE: "input validation" is "the input validation" mentioned in the RFC) If you have question, I don't mind at all to explain more. I think most of you misunderstood the concept. If you have other reason(s), please let me know to improve RFC. Thank you! Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
