[Tickets #13379] Re: Discontinue eval

[noreply at bugs.horde.org]

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.