Tickets :: Comment on [#13379] Discontinue eval

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ .__..__.. . [__)[__)\| \|[__]\|__\| \| \| \\|__\\| \|\| \|
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries