I'd like to reinstate the ability have the lisp side be able to evaluate arbitrary forms from presentation menus. If there is a security issue for some I think it would be better handled by having a switch to disable evaluation of these forms, with the default being that they are evaluated.
And to be honest, I can't see how disabling presentation menus from evaluating forms in emacs enhances security when one is already sitting in a repl talking to the lisp.
Also, the recent move of the inspect, describe, and copy to input functions to the emacs side removes the ability to specialize the method on the lisp side to not offer those choices. If there is good reason to move them over, which I'm not convinced of, then it would be better to still return a value, say a keyword, to represent these actions so that they can be overidden.
-Alan
Alan Ruttenberg alanr-l@mumble.net writes:
I'd like to reinstate the ability have the lisp side be able to evaluate arbitrary forms from presentation menus. If there is a security issue for some I think it would be better handled by having a switch to disable evaluation of these forms, with the default being that they are evaluated.
I had implemented such a switch for the protocol message `evaluate-in-emacs'. In my opinion, if a presentation-menu action wants to evaluate a form in Emacs, it should simply call `evaluate-in-emacs'. This simplifies the menu protocol.
However, Helmut has removed `evaluate-in-emacs' completely.
Helmut, could you comment whether it would be acceptable for you if we re-introduce evaluate-in-emacs (together with the security switch `slime-enable-evaluate-in-emacs'). It seems to be a feature that is useful for Alan (and others). (However, I think that the default should be a secure one, and that no default SLIME functionality should depend on it.)
Also, the recent move of the inspect, describe, and copy to input functions to the emacs side removes the ability to specialize the method on the lisp side to not offer those choices.
I don't see the point in not offering these choices. Isn't it good if these menu items are always available so that one can rely on them?
Also, in my opinion, it is much cleaner to handle these items in Emacs rather than relying on the feature of evaluating arbitrary code in Emacs.
* Matthias Koeppe [2005-09-10 14:49+0200] writes:
Alan Ruttenberg alanr-l@mumble.net writes:
I'd like to reinstate the ability have the lisp side be able to evaluate arbitrary forms from presentation menus. If there is a security issue for some I think it would be better handled by having a switch to disable evaluation of these forms, with the default being that they are evaluated.
I don't quite understand why a menu has to evaluate arbitrary ELisp code. Shouldn't Emacs just tell Lisp which menu item was selected? Or is needed for the kind of stuff people do with javascript in web-browsers?
BTW, are presentations of any use to people who don't use a mouse with Emacs?
I had implemented such a switch for the protocol message `evaluate-in-emacs'. In my opinion, if a presentation-menu action wants to evaluate a form in Emacs, it should simply call `evaluate-in-emacs'. This simplifies the menu protocol.
However, Helmut has removed `evaluate-in-emacs' completely.
Helmut, could you comment whether it would be acceptable for you if we re-introduce evaluate-in-emacs (together with the security switch `slime-enable-evaluate-in-emacs'). It seems to be a feature that is useful for Alan (and others). (However, I think that the default should be a secure one, and that no default SLIME functionality should depend on it.)
evaluate-in-emacs was redundant because there is already a swank:eval-in-emacs resp. slime-eval-for-lisp.
The "security" switch sounds a bit academic/useless to me, but I don't mind if you add one.
Helmut.
On Sep 10, 2005, at 9:47 AM, Helmut Eller wrote:
I don't quite understand why a menu has to evaluate arbitrary ELisp code. Shouldn't Emacs just tell Lisp which menu item was selected? Or is needed for the kind of stuff people do with javascript in web-browsers?
Where the menu is to take an action in emacs you need to tell emacs somehow what to do. It seemed easier to simply do that in one place rather than having to create both the menu action in lisp and a separate function in emacs. However, it would be equivalent to simply send the menu choice back to lisp and have lisp call swank:eval-in-emacs when appropriate.
I suppose this is a matter of nostalgia as well - I am used to the situation where the debugging/editing environment and the runtime are running together. Having the emacs code sitting in the same place made it feel less like I always had to worry about the mechanics of the connection.
BTW, are presentations of any use to people who don't use a mouse with Emacs?
You can copy them and reuse them as input. I can look in to providing a mechanism for accessing the menu choices via the keyboard.
The "security" switch sounds a bit academic/useless to me, but I don't mind if you add one.
I'm trying to understand where this would be a legitimate concern. The only situation I can imagine, given that you are in the repl already (and hence have full access to the lisp and emacs) is that you want to use slime to debug a potentially compromised lisp. In that case one could imagine whoever compromised the lisp waiting for you to connect with slime and then pounce on your emacs. Is that the situation you were thinking about Matthias?
The reason that I suggested that security be off by default is that this seemed to be a rather uncommon case and so why not put the burden on the uncommon case. However maybe there is a more common situation...
-Alan
Alan Ruttenberg alanr-l@mumble.net writes:
I'm trying to understand where this would be a legitimate concern. The only situation I can imagine, given that you are in the repl already (and hence have full access to the lisp and emacs) is that you want to use slime to debug a potentially compromised lisp. In that case one could imagine whoever compromised the lisp waiting for you to connect with slime and then pounce on your emacs. Is that the situation you were thinking about Matthias?
Yes, exactly.
If I connect to a compromised host by the FTP/TELNET/HTTP protocols, it is not desirable that the host can have my machine execute arbitrary code. I don't see why it should be different (by design!) if I connect to a compromised host by the SWANK protocol.
Helmut Eller heller@common-lisp.net writes:
evaluate-in-emacs was redundant because there is already a swank:eval-in-emacs resp. slime-eval-for-lisp.
Thanks for the explanation.
The "security" switch sounds a bit academic/useless to me, but I don't mind if you add one.
Done. I hope you don't mind that I made it secure by default, as no SLIME functionality depends on it.
-
Alan Ruttenberg -
Helmut Eller -
Matthias Koeppe