5 ms·

Define dangerous? Are you concerned with security? In which case, don't eval untrusted code, and you're fine. Maintainability? If done right "code is data" cou

Define dangerous? Are you concerned with security? In which case, don't eval untrusted code, and you're fine. Maintainability? If done right "code is data" could improve the maintainability, or decrease it drastically, just like any other feature. If you have 80 lines of comments for every 10 lines of code, you've decreased your maintainability, comments are dangerous by that logic.

pjungwir 14y ago
Yes, by "dangerous" I mean prone to security exploits. I've got nothing against Lisp--I think it's a beautiful language, and I've dabbled in CL, Scheme, and Clojure--but whenever I hear about using data as code I get a warning tingle in the back of my head. One of the lessons of the recent Ruby YAML debacle is that an executable data format will get used for untrusted input eventually somewhere or other. (Edit: For example I can totally imagine the digital circuits simulator from SICP 3.3.4 saving/reading Lisp code as an input document.) Maybe the power of Lisp's data-as-code is worth the risk. We don't stop using string concatenation because of SQL injection. It's just that I've never even read so much as a warning about this feature, and I'm curious what Lisp users have to say about it.
- pavelludiq 14y ago
  eval("dangerous python code here") As I pointed out, it is a problem in any language that has eval. The way you deal with it, is you never eval anything untrusted, which is actually extremely easy to do. I don't believe I've ever used eval ever. In CL specifically, because the reader can evaluate code as well, every time you use the read function, you should know these two things: 1) never use it for user input. 2) bind read-eval to nil. You'll be fine, or more accurately, no worse than anybody else :) On the other hand macros, and having a json style serialization format that is much more powerful and actually extensible is a big plus :)
  - sdkmvx 14y ago
    Is it actually dangerous to use read for user input? (defun read-data () (let ((data (let ((*read-eval* 'nil)) (read)))) (mapcar (lambda (x) (format 't "~a: ~a~%" (car x) (cdr x))) data))) Then I can (read-data) (("a" . 1) ("b" . 2) ("c" . (funcall (lambda () (princ "I ran code!"))))) And the following will print. a: 1 b: 2 c: (FUNCALL (LAMBDA () (PRINC I ran code!))) But of course unless I eval the code, arbitrary code will not run (assuming I haven't forgotten some aspect of the reader).
- betterunix 14y ago
  "It's just that I've never even read so much as a warning about this feature" ...have you really looked? Here is a warning, in the section titled, "Reader Security:" http://letoverlambda.com/index.cl/guest/chap4.html http://letoverlambda.com/index.cl/guest/chap4.html
  - pjungwir 14y ago
    > have you really looked? To be fair, no. I'm not a practicing Lisp programmer; I just admire the language. But I've read a fair number of Lisp tutorials, as well as SICP, and I don't recall it being mentioned. I'm glad it's out there somewhere!
- spacemanaki 14y ago
  I don't buy your example from chapter 3 of SICP. You could just as easily serialize Python code and eval it. That would be bad practice in Python and it would be in Lisp. The power of "code is/as data" means that Lisp macros can manipulate code as easily as other Lisp code manipulates data. It's not really about eval.
  - pjungwir 14y ago
    > You could just as easily serialize Python code and eval it. That seems to be the consensus among all the people replying to me. :-) Fair enough. The difference I see is that lots of Lisp authors praise "no syntax" and code-as-data, so it seems to be encouraged, whereas I don't see Python programmers encouraging use of eval. Lisp seems designed for this kind of meta-programming. And it's really cool! It just makes me nervous. As an outsider, I really appreciate the responses from you all. Basically you seem to be saying, "It's not an issue. We use it for macros, not for untrusted inputs. Don't call eval and you're fine." Obviously I wouldn't want you to do anything else. :-) Anyway, thanks for the replies. It's great to have a community where I can ask Lisp users about something like this and learn what they think! It's something I've wondered about for a long time.

pjungwir 14y ago

Yes, by "dangerous" I mean prone to security exploits. I've got nothing against Lisp--I think it's a beautiful language, and I've dabbled in CL, Scheme, and Clojure--but whenever I hear about using data as code I get a warning tingle in the back of my head. One of the lessons of the recent Ruby YAML debacle is that an executable data format will get used for untrusted input eventually somewhere or other. (Edit: For example I can totally imagine the digital circuits simulator from SICP 3.3.4 saving/reading Lisp code as an input document.) Maybe the power of Lisp's data-as-code is worth the risk. We don't stop using string concatenation because of SQL injection. It's just that I've never even read so much as a warning about this feature, and I'm curious what Lisp users have to say about it.

pavelludiq 14y ago
eval("dangerous python code here") As I pointed out, it is a problem in any language that has eval. The way you deal with it, is you never eval anything untrusted, which is actually extremely easy to do. I don't believe I've ever used eval ever. In CL specifically, because the reader can evaluate code as well, every time you use the read function, you should know these two things: 1) never use it for user input. 2) bind read-eval to nil. You'll be fine, or more accurately, no worse than anybody else :) On the other hand macros, and having a json style serialization format that is much more powerful and actually extensible is a big plus :)
- sdkmvx 14y ago
  Is it actually dangerous to use read for user input? (defun read-data () (let ((data (let ((*read-eval* 'nil)) (read)))) (mapcar (lambda (x) (format 't "~a: ~a~%" (car x) (cdr x))) data))) Then I can (read-data) (("a" . 1) ("b" . 2) ("c" . (funcall (lambda () (princ "I ran code!"))))) And the following will print. a: 1 b: 2 c: (FUNCALL (LAMBDA () (PRINC I ran code!))) But of course unless I eval the code, arbitrary code will not run (assuming I haven't forgotten some aspect of the reader).
betterunix 14y ago
"It's just that I've never even read so much as a warning about this feature" ...have you really looked? Here is a warning, in the section titled, "Reader Security:" http://letoverlambda.com/index.cl/guest/chap4.html http://letoverlambda.com/index.cl/guest/chap4.html
- pjungwir 14y ago
  > have you really looked? To be fair, no. I'm not a practicing Lisp programmer; I just admire the language. But I've read a fair number of Lisp tutorials, as well as SICP, and I don't recall it being mentioned. I'm glad it's out there somewhere!
spacemanaki 14y ago
I don't buy your example from chapter 3 of SICP. You could just as easily serialize Python code and eval it. That would be bad practice in Python and it would be in Lisp. The power of "code is/as data" means that Lisp macros can manipulate code as easily as other Lisp code manipulates data. It's not really about eval.
- pjungwir 14y ago
  > You could just as easily serialize Python code and eval it. That seems to be the consensus among all the people replying to me. :-) Fair enough. The difference I see is that lots of Lisp authors praise "no syntax" and code-as-data, so it seems to be encouraged, whereas I don't see Python programmers encouraging use of eval. Lisp seems designed for this kind of meta-programming. And it's really cool! It just makes me nervous. As an outsider, I really appreciate the responses from you all. Basically you seem to be saying, "It's not an issue. We use it for macros, not for untrusted inputs. Don't call eval and you're fine." Obviously I wouldn't want you to do anything else. :-) Anyway, thanks for the replies. It's great to have a community where I can ask Lisp users about something like this and learn what they think! It's something I've wondered about for a long time.