Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57735
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU7mYOB6RTHPFb8B76bPsZiFki6J5sJCMViGD7vK8Fdiyg@mail.gmail.com>
References: <CAF+90c9qoyzBf+FpBxMdX0FByy5xB+7x3xi3kNxdvWX=_uz=mg@mail.gmail.com>
	<CAEZPtU7mYOB6RTHPFb8B76bPsZiFki6J5sJCMViGD7vK8Fdiyg@mail.gmail.com>
Date: Sun, 5 Feb 2012 17:51:14 +0100
Message-ID: <CAH-PCH6Aqh1oW+jSjVsJwzs=Og9pBQmXV+ckRqFOs1gXadq6sg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=00248c7117959ed5eb04b83a5ae0
Subject: Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace
From: tyra3l@gmail.com (Ferenc Kovacs)

--00248c7117959ed5eb04b83a5ae0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 5, 2012 at 5:21 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> 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_rem=
ove_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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--00248c7117959ed5eb04b83a5ae0--