librelist archives

« back to archive

Re: [leiningen] Steps to test Leiningen with my own private Clojure version?

Re: [leiningen] Steps to test Leiningen with my own private Clojure version?

From:
Phil Hagelberg
Date:
2013-02-22 @ 18:10
Andy Fingerhut writes:

> Color me ignorant on building Leiningen from source, and even 
> whether Leiningen uses its own included version of Clojure 
> within its distribution, and whether that matters for this 
> question. 
 
From what I can tell of what you're asking the version of Clojure 
that Leiningen uses for itself doesn't come into play for this. 
Leiningen itself never calls the reader on untrusted data, so it's 
only relevant in the context of a project. (via eval-in-project) 
The version of Clojure used by the project is isolated from the 
version Leiningen uses for itself. 
 
> I'm working on http://dev.clojure.org/jira/browse/CLJ-1168
>
> Am I correct in believing that if this issue is left unchanged, 
> it would mean that if and when someone:
>
>     (a) wanted a Leiningen project using Clojure 1.5.0 and
>     (b) wanted to use the new clojure.read.eval=unknown command 
>     line option to the JVM to help find unsafe uses of 
>     clojure.core/read or read-string
>
> then any Leiningen task that invoked "java" with 
> -Dclojure.read.eval=unknown and the -e option would fail?  It 
> appears that with Leiningen 2.0.0 at least "lein test" uses the 
> -e option on the java command line, and I'm guessing there are 
> others.  Corrections welcome.
 
No, the test task only uses the reader inside the Leiningen 
process itself; it never invokes the reader inside the context of 
the process. 

> Does anyone know whether Leiningen currently uses #=(expr) or 
> #java.my.favorite.constructor expressions in the strings it 
> gives after the -e option?  If it already does, or can, or you 
> think someone might want to do that, then binding *read-eval* to 
> true would be necessary.

Leiningen itself doesn't use those, but there might be some plugins that do.

-Phil

Re: [leiningen] Steps to test Leiningen with my own private Clojure version?

From:
Andy Fingerhut
Date:
2013-02-22 @ 23:53
Thanks for the answers, Phil.  My apologies that the subject line and body
of my original message didn't really match -- I forgot to update the 
subject line after writing a different message than I originally intended.

In the forthcoming Clojure 1.5.0, it has a command line option 
-Dclojure.read.eval=unknown that causes any call to clojure.core/read or 
read-string to throw an exception, unless the program first explicitly 
binds *read-eval* to either true or false.  The intent is to help a 
developer find such calls and replace them with safe versions if needed, 
e.g. the edn reader in the new tools.reader contrib library.

Before Clojure 1.5.0-RC17, if a developer put [:jvm-opts 
"-Dclojure.read.eval=unknown] in their project.clj file and tried a task 
like "lein run", that exception would be thrown because *read-eval* still 
had the bad :unknown file while reading the string that Leiningen gives 
after the -e option on the java command line.  So that 
help-find-unsafe-reads feature would have been broken with Leiningen.

With Clojure 1.5.0-RC17, that will work, because *read-eval* is bound to 
true while reading the string after the -e option.

With or without that fix, I'm not aware of any problems if you didn't 
specify the -Dclojure.read.eval=<val> option in :jvm-opts.

Hope that's clear.

Thanks,
Andy

On Feb 22, 2013, at 10:10 AM, Phil Hagelberg wrote:

> 
> Andy Fingerhut writes:
> 
>> Color me ignorant on building Leiningen from source, and even 
>> whether Leiningen uses its own included version of Clojure 
>> within its distribution, and whether that matters for this 
>> question. 
> 
>> From what I can tell of what you're asking the version of Clojure 
> that Leiningen uses for itself doesn't come into play for this. 
> Leiningen itself never calls the reader on untrusted data, so it's 
> only relevant in the context of a project. (via eval-in-project) 
> The version of Clojure used by the project is isolated from the 
> version Leiningen uses for itself. 
> 
>> I'm working on http://dev.clojure.org/jira/browse/CLJ-1168
>> 
>> Am I correct in believing that if this issue is left unchanged, 
>> it would mean that if and when someone:
>> 
>>    (a) wanted a Leiningen project using Clojure 1.5.0 and
>>    (b) wanted to use the new clojure.read.eval=unknown command 
>>    line option to the JVM to help find unsafe uses of 
>>    clojure.core/read or read-string
>> 
>> then any Leiningen task that invoked "java" with 
>> -Dclojure.read.eval=unknown and the -e option would fail?  It 
>> appears that with Leiningen 2.0.0 at least "lein test" uses the 
>> -e option on the java command line, and I'm guessing there are 
>> others.  Corrections welcome.
> 
> No, the test task only uses the reader inside the Leiningen 
> process itself; it never invokes the reader inside the context of 
> the process. 
> 
>> Does anyone know whether Leiningen currently uses #=(expr) or 
>> #java.my.favorite.constructor expressions in the strings it 
>> gives after the -e option?  If it already does, or can, or you 
>> think someone might want to do that, then binding *read-eval* to 
>> true would be necessary.
> 
> Leiningen itself doesn't use those, but there might be some plugins that do.
> 
> -Phil