Index: slime/ChangeLog diff -u slime/ChangeLog:1.756 slime/ChangeLog:1.759 --- slime/ChangeLog:1.756 Sat Aug 27 18:37:56 2005 +++ slime/ChangeLog Sun Aug 28 17:09:46 2005 @@ -1,3 +1,27 @@ +2005-08-28 Matthias Koeppe mkoeppe@mail.math.uni-magdeburg.de + + * slime.el (slime-repl-kill-input): New command. + (slime-repl-mode-map): Bind it to C-c C-u, like in comint. + (slime-repl-easy-menu): Include it in the REPL menu. + + * swank-backend.lisp (make-weak-key-hash-table) + (make-weak-value-hash-table): New interfaces. + * swank-cmucl.lisp (make-weak-key-hash-table): Implement it. + * swank-sbcl.lisp (make-weak-key-hash-table): Implement it. + * swank-openmcl.lisp (make-weak-key-hash-table) + (make-weak-value-hash-table): Implement it. + + * swank.lisp (*object-to-presentation-id*) + (*presentation-id-to-object*): Use new functions + make-weak-key-hash-table, make-weak-value-hash-table. + + * slime.el (slime-enable-evaluate-in-emacs): New variable. + (evaluate-in-emacs): Security improvement: If + slime-enable-evaluate-in-emacs is nil (the default), don't + evaluate forms sent by the Lisp. + + * swank.lisp (send-to-socket-io): Handle :evaluate-in-emacs. + 2005-08-27 Matthias Koeppe mkoeppe@mail.math.uni-magdeburg.de
* slime.el (slime-presentation-menu): When an object is no longer
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
grep says that eval-in-emacs is being used in the CMUCL and LispWorks backends. If this should be disallowed by default I think those bits need to be replaced with real protocol messages instead of evals.
Cheers, Luke
Luke Gorrie luke@synap.se writes:
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
grep says that eval-in-emacs is being used in the CMUCL and LispWorks backends. If this should be disallowed by default I think those bits need to be replaced with real protocol messages instead of evals.
Thanks for pointing this out; I'll look into it.
On Mon, 29 Aug 2005 11:01:37 +0200, mkoeppe+slime@mail.math.uni-magdeburg.de wrote:
Luke Gorrie luke@synap.se writes:
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
grep says that eval-in-emacs is being used in the CMUCL and LispWorks backends. If this should be disallowed by default I think those bits need to be replaced with real protocol messages instead of evals.
Thanks for pointing this out; I'll look into it.
Huh?? You didn't look first? You don't know what your mod breaks?
Can this be rolled back until it is investigated please?
GP lisper spambait@CloudDancer.com writes:
Huh?? You didn't look first? You don't know what your mod breaks?
Steady on there, these things happen :-)
On 29 Aug 2005 21:48:49 +0200, luke@synap.se wrote:
GP lisper spambait@CloudDancer.com writes:
Huh?? You didn't look first? You don't know what your mod breaks?
Steady on there, these things happen :-)
Yes.
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Luke Gorrie luke@synap.se writes:
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
grep says that eval-in-emacs is being used in the CMUCL and LispWorks backends. If this should be disallowed by default I think those bits need to be replaced with real protocol messages instead of evals.
Thanks for pointing this out; I'll look into it.
Done.
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Luke Gorrie luke@synap.se writes:
grep says that eval-in-emacs is being used in the CMUCL and LispWorks backends. If this should be disallowed by default I think those bits need to be replaced with real protocol messages instead of evals.
Thanks for pointing this out; I'll look into it.
Done.
Thanks!
-Luke
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
what is the security risk (which isn't already present just by having slime connected) which evaluate-in-emacs adds? do you often connect slime to untrusted swank servers? or can swank somehow connect itself to emacs (this would be really cool btw)?
"Marco Baringer" mb@bese.it writes:
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
what is the security risk (which isn't already present just by having slime connected) which evaluate-in-emacs adds?
The Lisp program could reside on an untrusted host. It should not be allowed to execute arbitrary code on the host where Emacs runs.
On Mon, 29 Aug 2005 11:06:16 +0200, mkoeppe+slime@mail.math.uni-magdeburg.de wrote:
"Marco Baringer" mb@bese.it writes:
lgorrie@common-lisp.net (Luke Gorrie) writes:
- slime.el (slime-enable-evaluate-in-emacs): New variable.
- (evaluate-in-emacs): Security improvement: If
- slime-enable-evaluate-in-emacs is nil (the default), don't
- evaluate forms sent by the Lisp.
what is the security risk (which isn't already present just by having slime connected) which evaluate-in-emacs adds?
The Lisp program could reside on an untrusted host. It should not be allowed to execute arbitrary code on the host where Emacs runs.
The kind of connections you've already made by the time this is important put you into much deeper trouble with a compromised host.
If you don't trust the other end, you shouldn't be doing any host interaction beyond delivering files. If you don't trust the other end, you shouldn't be using an important user account, but rather a throw-away user account, to deal with an untrusted host. I see no additional value here.
-
GP lisper -
lgorrie＠common-lisp.net -
Luke Gorrie -
Marco Baringer -
Matthias Koeppe