Re: [PEPr] Comment on RFC::EvalForbiddance
| From: | Scott Mattocks | Date: | Tue, 16 Aug 2005 13:59:02 +0000 |
| Subject: | Re: [PEPr] Comment on RFC::EvalForbiddance | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-39411@lists.php.net to get a copy of this message | ||
Martin Jansen wrote:
Martin Jansen (http://pear.php.net/user/mj) has commented on the proposal for RFC::EvalForbiddance. Comment: I believe this in fact is necessary. If all packages undergo serious peer reviews already, then why didn't we spot the issue in XML_RPC until Stefan pointed us to it? Don't get me wrong -- I'm certainly not considering to ban more functions, but I believe that eval() is probably the best way to shoot yourself in the foot with PHP these days.I know that no one is going to turn around a propose that we ban strpos() tomorrow but once we have the idea of banned functions we open ourselves up for more problems. The next one on the list will probably be __autoload() and if you can make an argument to ban that one then it wouldn't be too hard to get __call() banned and then another function and another... Setting up a rule doesn't mean that uses of eval will be caught. It still requires someone to go through all of the code and look for it. Just like it does now. Security issues won't be removed by writing an RFC. They can only be solved by peer review. If we as a group put as much effort into checking for security holes as we do coding style, this type of RFC wouldn't be needed. Scott