3 ms·

I think this is an excellent write-up of the state of the world with Clojure 1.5: http://clojuredocs.org/clojure_core/clojure.core/read http://clojuredocs.org/c

I think this is an excellent write-up of the state of the world with Clojure 1.5: http://clojuredocs.org/clojure_core/clojure.core/read http://clojuredocs.org/clojure_core/clojure.core/read In short, don't use read-eval at all if you want safe reading. Use the clojure.edn alternatives to read data safely in those circumstances.

jfb 14y ago
In addition, I was very happy to see it presented as valid Clojure with explicating commentary, rather than as an information-light "screencast".
willismichael 14y ago
;; The particular issue of executing arbitrary Java constructors used ;; in the examples above no longer works in Clojure 1.5 when ;; *read-eval* is false. Even so, you SHOULD NEVER USE ;; clojure.core/read or clojure.core/read-string for reading untrusted ;; data. Use an edn reader or a different data serialization format. From that comment it seems like the Java constructor loophole has been closed. With that gone, I don't understand why the reader is still dangerous. What am I missing?
- mjw 14y ago
  I was wondering this too, and deliberately tried to break something using the clojure 1.5 reader with read-eval false. (Makes a change from building things all day!). Result: user=> (binding [*read-eval* false] (read-string "``````````x")) OutOfMemoryError Java heap space clojure.lang.RT.cons (RT.java:570)
- bjeanes 14y ago
  There's a huge IRC log that explains the reasoning here. Mostly, it comes down to: you can't trust that libraries haven't changed read-eval back, which means that now instead of being assured that a certain fn can never be harmful, you would need to audit all libraries you use. It's the assumption itself (that read and read-string are safe) what makes it unsafe...