* Helmut Eller m2abjrg1y9.fsf@common-lisp.net : Wrote on Fri, 18 Apr 2008 07:35:26 +0200:
| * Madhu [2008-04-18 00:45+0200] writes: |> What is your excuse to keep this backdoor mechanism to allow loading of |> arbitrary code behind the user's back, assuming you can write the |> ChangeLog file? | | SLIME is supposed to be used in a secure environment and we don't make | any claims that SLIME is in any way secure. I don't see the point of | complicating the code for such non-problems.
Sorry, I don't buy that reason. Binding *READ-EVAL* to NIL when calling READ on non-lisp source files is not complicated. The change I suggested in m33appm1vm.fsf@robolove.meer.net is one line:
* ,[14 Apr 2008 11:09:09 +0530:] | -(defun slime-version-string () | +(defun slime-version-string (&aux *read-eval*)
Besides, not only is it not complicating things, it is The Right Thing To Do. The code is doing the wrong thing if it does not bind reader variables before calling read. Let me repeat, binding *READ-EVAL* to NIL when calling READ on non-lisp source forms, when you are expecting DATA is the Right Thing To Do in lisp.
In Common Lisp, this issue can be considered "equivalent" to buffer overflow in C. What you are defending is akin to defending the use of gets(3), and inviting buffer overflow problems, despite having beein informed that gets(3) is buggy and you should use fgets instead. I can't understand that attitude either!
Of course you are the boss, feel free not to fix it :)
-- Madhu
(Now available for SLIME/CL consulting :-})