[Tickets #13379] Re: Discontinue eval
noreply at bugs.horde.org
noreply at bugs.horde.org
Mon Aug 11 18:56:34 UTC 2014
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/13379
------------------------------------------------------------------------------
Ticket | 13379
Updated By | Michael Slusarz <slusarz at horde.org>
Summary | Discontinue eval
Queue | IMP
Version | 6.2.0
Type | Enhancement
-State | Feedback
+State | Resolved
Priority | 1. Low
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
Michael Slusarz <slusarz at horde.org> (2014-08-11 12:56) wrote:
>> Nobody has shown that our code is subject to any security issue.
>
> I certainly did not claim that. I don't know where you see such a
> claim in my bugreport.
Then that is my fault and I apologize.
Then again, that is really the only reason why anybody would recommend
refactoring code so it wasn't an out of nowhere assumption.
>> Use of eval() is perfectly acceptable. I see way too many people who
>> say things like "eval() should NEVER be used". Which is flat-out
>> wrong. eval() is no more dangerous than anything else - meaning it
>> can be abused if used incorrectly.
>
> Uhm, I am a bit baffled, as I did not expect this kind of argument.
>
> Of course the use of eval is not necessarily dangerous, in the same
> way it is perfectly safe for skilled people to swallow a sword. It
> is however pretty easy to make a mistake and face severe consequences.
This is starting to sound like the suhosin way of "security". Which
is: "somebody can potentially write code that *might* be possibly
dangerous in some circumstances, so the solution is to prevent that
code from ever being written." (Suhosin for C would allow you to do
nothing more than output static strings, since memory allocation can
possibly be dangerous when done by people who don't know what they are
doing, so we can't allow that.)
> Of course not using eval is not some magic potion, but it is
> certainly a step in the right direction in my opinion.
Disagree from a security perspective (for our project). Agree from a
performance/cleaner design perspective (for our project).
>> I'm not saying that removing eval() is not something we should strive
>> for from a *design* perspective.
>
> That was exactly my proposal.
>
>> But I'm not sure what your
>> alternative is.
>
> Uhm how about:
> document.createElement('script').src = '/myShinyNewScript.js';
This requires another connection to the server. Can't assume this
code is cached. Can't assume you have a fast network connection. So
this is not equivalent replacement code.
Going to close. eval() with autocomplete is going away (or has
already been removed - can't remember), since server interaction
paradigm has changed in git master. Other existing eval() code is
fine for reasons I've stated previously.
More information about the bugs
mailing list