[slime-devel] Re: [PATCH] Bind *read-eval* in slime-version-string
Madhu
enometh at meer.net
Mon Apr 21 08:31:28 UTC 2008
* Helmut Eller <m2abjrg1y9.fsf at 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 at 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 :-})
More information about the slime-devel
mailing list