> -----Original Message----- > From: Derick Rethans [mailto:der...@php.net] > Sent: Sunday, February 05, 2012 11:46 AM > To: Nikita Popov > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from > preg_replace > > On Sun, 5 Feb 2012, Nikita Popov wrote: > > > I have written an RFC that proposes to *deprecate* and *remove* the /e > > modifier: > > > > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier > > > > Comments welcome! > > This RFC makes no sense. It says: > > For example the above example can be used to execute arbitrary PHP code by > passing the string <h1>{${eval($_GET[php_code])}}</h1>. The evaluted code in > this case would be "<h1>" . strtoupper("{${eval($_GET[php_code])}}") . "</h1>" and as such execute any PHP code passed in the php_code GET variable. > > If you don't sanitize your imput than all sorts of intesting things can't > happen. You're going to inconvenience a lot of people by removing it. > > So, definitely against removing features from a language with no real win. > > cheers, > Derick
Normally I'd totally agree with not removing stuff, but in this case the RFC makes a critical error which serves to demonstrate exactly how bad the problem is. The author incorrectly used double quotes in their replace string, when the only safe solution is to use single quotes. This is a super common mistake with /e, and even many veterans won't notice it (although they'll probably notice the use of /e). Removing this would obviously be an inconvenience for some people, but getting your server hacked is also an inconvenience, and hackers don't give you nice warnings with file and line number. I like the idea of doing _something_ here. Deprecate now and remove later sounds fair. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
