On Sat, 2011-07-23 at 03:03 -0700, Jozef Wagner wrote: > That's why *read-eval* should IMHO default to false. Anybody knows the > reason why it doesn't?
-1 > > On Saturday, July 23, 2011 10:35:40 AM UTC+2, Mark Derricutt wrote: > ...and immediately a new attack vector is born with Clojure > structure injection attacks... > > > I so hope people don't start passing executable clojure back > and forth. I believe that Rich said that the runtime eval would not be available in clojurescript. If you don't want your application to execute code then set *read-eval* to false, defn eval to do nothing, write a custom reader (e.g. a JSON reader) that you invoke, stomp on the # reader dispatch by writing a dispatch-reader-macro, etc. Tend to favor permissive environments that can be locked down rather than restrictive environments that limit. It is unlikely that there will be agreement on this issue but I do think that the *default* behavior should be the same everywhere. Flipping the default *read-eval* is security-by-fig-leaf. I *DO* hope that people start passing executable clojure back and forth. After all, program == data, so what exactly is "non-executable"? Why would you want to write a parser for lisp "data" when it already IS parsed? Done right, you can just eval the "data" as a program and it "just works". It is simple, elegant, it requires no extra code, and it adapts dynamically to changes in the "data" without effort or bugs. Your whole DSL is just an executable "data" structure. By fooling around with macros you can make the same DSL print as XML or JSON or "execute". Try not to separate the idea of programs from the idea of data. "Executing" the "data" in the reader is a perfectly reasonable thing to do. ...[snip]... Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
