[RFC] Deprecate and remove /e modifier from preg_replace

I know a straw man argument when I see one (: /e suggests that eval is a casual thing to be sprinkled into typical search and replace operations. It also suggests that putting PHP code in a quoted string is probably the easy way to solve your problem. It's often discovered before the developer has even heard of preg_replace_callback. eval() does not have these PR problems (: It's there for those who are truly looking for it. On Sun, Feb 5, 2012 at 11:21 AM, Pierre Joye <pierre.php@gmail.com> wrote:

what he hell - if you kill eval you would kill the whole work of my life and yes i know that eval is evil and it is only used at one place which is a central and real important to include modules and set parameters dynamically the /e modifier is a total other dimension because it can be used by people not knowing what they are doing exactly by C&P any code snippet eval() is a documentated function Am 05.02.2012 17:21, schrieb Pierre Joye:

On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye <pierre.php@gmail.com> wrote:

https://wiki.php.net/rfc/remove_preg_replace_eval_modifier#but_we_don_t_remove_eval_either_do_we I think it would be very unwise to start bringing up that here, when the RFC author explicitly stated that his RFC is not about removing eval. From my POV, the problem with /e is that it is easy miss the fact that using unfiltered user input in your preg_replace call can lead to arbitrary code execution. With eval() you explicitly state that you want this, and if you miss the security implications of your actions, you can blame nobody but yourself. Another difference is that as the RFC states, the /e modifier can be replaced easily with a callback, which would make the code even more clear, so it is an even better alternative. On the other hand, eval doesn't have such an easy alternative, you would have to generate and save the code and include it, which has the same security implications but it is much more tendersome, and it would also open up potential security implications (another process overwriting your temp file would cause arbitrary code execution for example, so one would need to use hard-to-guess filenames and/or exclusive locking, or using custom streams, etc.). To summarize /e has less use cases than eval and it has an alternative which provides better code, which isn't true for eval.

strtoupper("{${eval($_GET[php_code])}}") . "</h1>" and as such execute any PHP code passed in the php_code GET variable.

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.