3 ms·
;; 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.
by 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 agoI 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 agoThere'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...