Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Document *read-eval* in read, read-string

Description

Even though the #=() reader syntax is "unofficial", *read-eval* should be documented in the appropriate API functions – this is a serious security problem for anyone accepting serialized Clojure data structures. E.g., a system service reading a config file, a server accepting an API request.

Environment

None

Attachments

1

Activity

Show:

Andy Fingerhut February 6, 2013 at 6:38 PM

With the recent changes Rich has done to add read-edn and read-edn-string, he has also updated the doc strings of read and read-string to call out the potential security dangers, emphasize that they are intended for use only in reading code and/or data from trusted sources, and to point to the safer read-edn and read-edn-string for data interchange purposes.

The purpose of this ticket seems to be satisfied with those commits.

Andy Fingerhut January 30, 2013 at 4:52 PM

See also the newer ticket CLJ-1153, which has a patch to change read-eval default value to false.

Steve Miner January 30, 2013 at 4:44 PM

It would be useful to document the interaction between *print-dup* and *read-eval* as well. In most cases, if you use *print-dup* true to preserve exact types, you'll want to bind *read-eval* true to read them. Code that depends on their default values is brittle.

Steve Miner January 30, 2013 at 4:15 PM

See also discussion on the mailing list:
https://groups.google.com/forum/?fromgroups=#!topic/clojure/qUk-bM0JSGc

Several people who care about safety think that *read-eval* should be false by default. Documentation does not make up for a security hole.

Christopher Redinger November 27, 2012 at 11:36 PM

Patch applies cleanly and adds a useful message.

Completed

Details

Assignee

Reporter

Approval

Vetted

Patch

Code

Priority

Affects versions

Created December 31, 2011 at 3:39 PM
Updated February 22, 2013 at 3:02 PM
Resolved February 22, 2013 at 3:02 PM