Main holes that this closes are:
1. Being able to run code fetched remotely without ever hitting disk
2. Being able to run code transformed directly from an obfuscated state
I have examples of both techniques; reply directly to me if you're curious.
One of the examples breaks if create_function i
y,
leaving it on for the CLI).
On Tue, Nov 26, 2019 at 3:44 PM Mike Schinkel wrote:
> On Nov 26, 2019, at 11:27 AM, Ian Littman wrote:
>
>
> You're right that turning off eval() isn't a silver bullet, and if you can
> get external code running on someone's box t
Thanks for the reference. For convenience, here's the PR that contains a
bit more context: https://github.com/php/php-src/pull/4084
Definitely don't want to screw up Xdebug, so this would require a more
nuanced approach (see also: why I don't want to just try to create a patch).
Again, this doesn
ld
> be annoying for libraries relying (sparingly) on it, for lack of anything
> better.
>
> Best,
> Benjamin
>
> Le 26 nov. 2019 à 16:52, Ian Littman a écrit :
>
> Hi all,
>
> Let's just say that eval() and create_function() are the cornerstone of
> PH
Looks like PHPUnit only uses eval() for mock objects, and Twig only uses it
as a last line of defense for building templates. Still breakages, but not
of the entire packages (at least those packages) from what I can see.
That said, I agree that eval() should stay enabled by default, as too much
br
down if
I try going down that road...and if other folks like the idea, I could use
some help here putting it together.
What do y'all think about getting this into PHP 8?
Thanks in advance,
Ian Littman
