[RFC] Deprecate and remove /e modifier from preg_replace View as Markdown

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.

hi,

I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow that).

Cheers,

Hi internals!

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!

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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:

I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow that).

Cheers,

Hi internals!

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!

hi,

I think we should remove eval at the same time then. As the risk is
exactly the same in both situations. Eval is just as evil and can be
avoided as well (or any other similar features, not sure if other exts
allow that).

Cheers,

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.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

-----Original Message-----
From: Derick Rethans [mailto:derick@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

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.