Hi all,
It looks like Rich has selected an approach to addressing *read-eval*, #=, and
related issues. The sands may still be shifting a bit, but far less than e.g.
earlier this week. With that in mind, I thought it might be helpful to point
to three authoritative messages from the
Hi Baishampayan,
I got such errors when I first started working on the patch; they were caused
by the compiler using print-dup'd strings to create namespaces instead of
emitting bytecode (which the patched build includes). Is it possible that you
have both an org.clojure/clojure jar and the
I put the canonical clojure artefact in a global exclusions vector in
my project.clj. The classpath doesn't have any duplicate clojure jar
in it. I was testing it out with `lein repl`, since swank-clojure is
broken in different ways.
Regards,
BG
On Sat, Feb 2, 2013 at 7:43 PM, Chas Emerick
By the way, this is how swank-clojure 1.4.4 is failing to compile with
the patched clojure jar -
Exception in thread main java.lang.IllegalArgumentException: No
matching ctor found for class clojure.lang.Compiler$CompilerException,
compiling:(swank/commands/basic.clj:183:24)
at
Ah, I didn't grok that you were reporting two separate breakages (one in swank,
one in your app).
I think the problem is in how the lein-swank plugin sets up dependencies (or,
how Leiningen itself applies :exclusions). If you don't have an
org.clojure/clojure dependency in your project, then
One thing that hasn't been mentioned so far is that AOT-compiled classfiles
generated using prior builds of Clojure will not load using a build of Clojure
that includes a patch like this. Just something to consider for those of you
taking the time to test, etc.
- Chas
--
--
You received
On Jan 31, 2013, at 8:03 PM, Chas Emerick wrote:
On Jan 30, 2013, at 5:59 PM, Michał Marczyk wrote:
On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
RuntimeException EvalReader not allowed when *read-eval* is false.
I have added a patch to CLJ-1153 that appears to address the *read-eval*
problem:
http://dev.clojure.org/jira/browse/CLJ-1153?focusedCommentId=30523#comment-30523
code on github:
https://github.com/cemerick/clojure/commit/1f5c19c07443d2535ede4ff71d23b40c195d617f
artifact on Clojars:
Just did some testing with our code-base and Clojure 1.5.0-RC4 (with
and without Chas' read-eval patch).
There is definitely something strange going on. Things worked just
fine with 1.5.0-RC4 but with the read-eval patch `lein swank` is
completely broken but more than that, our code is failing to
On Jan 30, 2013, at 5:59 PM, Michał Marczyk wrote:
On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
RuntimeException EvalReader not allowed when *read-eval* is false.
The problem is that the second eval gets (the actual +
This isn't what you are asking, but I wanted to make a comment that there is a
proposed patch to Clojure attached to ticket CLJ-904 that adds warnings to read
and read-string about how their behavior depends upon the value of *read-eval*:
http://dev.clojure.org/jira/browse/CLJ-904
Also,
This is exactly the thread that I meant to start a couple of weeks ago. Thanks
for giving me the kick in the pants, Takahiro. :-)
What brought the issue to the fore for me:
* a greatly increased interest in security issues due to my own work's
requirements
* the most recent arbitrary code
The most simple thing would be to change the default value of *read-eval*
to false...
Marek
On Wednesday, January 30, 2013 8:02:54 AM UTC+1, Takahiro Hozumi wrote:
As more and more projects are using edn format for config,
communication and etc, I think that default value of *read-eval*,
On Wed, Jan 30, 2013 at 10:18 AM, Marek Šrank markus.mas...@gmail.comwrote:
The most simple thing would be to change the default value of *read-eval*
to false...
Understanding that this may break existing code (how much?), I think it
would reflect well on the community to make decisions to
I like the idea of setting the default to false. This potentially does
break some code, but perhaps it breaks unknowingly insecure code - which is
a pretty big bonus.
I'd love it if I upgraded to a new release of Clojure and my app toppled
down because of my own shortsightedness.
An
On Wed, Jan 30, 2013 at 1:02 AM, Takahiro Hozumi fat...@googlemail.comwrote:
As more and more projects are using edn format for config,
communication and etc, I think that default value of *read-eval*,
which is true, is source of vulnerability such as recently reported
ring issue [1].
Out of curiosity, I made a patch to Clojure that causes the default value of
*read-eval* to be false instead of true, to see if any of the tests pass, and
to let other people try it out in case it breaks things that would be
surprising and/or disruptive. It is attached to this new ticket:
RuntimeException EvalReader not allowed when *read-eval* is false.
The problem is that the second eval gets (the actual + function 1 2
3) which invokes the right pathway triggering the exception. You can
trigger the same exception by:
(binding [*read-eval* false] (eval (list + 1 2 3)))
People
Although let me say that I agree with false being the default. I'm
not saying that is a bad idea, only that we need to be careful if
evaling what comes over... but I guess that is obvious and if not then
we get what we deserve. ;-)
On Wed, Jan 30, 2013 at 12:23 PM, Michael Fogus
Kyle R. Burton writes:
Understanding that this may break existing code (how much?), I think it
would reflect well on the community to make decisions to improve safety and
security, especially with respect to defaults like this. Avoiding
surprises after deployment is a virtue in my option.
I think the objective is to make read, read-string, etc. safe. Explicit use of
eval is what it is...short of sandboxing, you're opting into all that eval
implies.
- Chas
Michael Fogus mefo...@gmail.com wrote:
RuntimeException EvalReader not allowed when *read-eval* is false.
The problem is
I would prefer that *read-eval* default to false. In this case, security is
more important than backwards compatibility.
However, I want to point out that there is an issue with backwards
compatibility, especially for users of *print-dup* (default false). In many
cases, with *print-dup*
On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
RuntimeException EvalReader not allowed when *read-eval* is false.
The problem is that the second eval gets (the actual + function 1 2
3) which invokes the right pathway triggering the exception. You can
trigger the same exception by:
On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
On Jan 30, 2013, at 12:23 PM, Michael Fogus wrote:
RuntimeException EvalReader not allowed when *read-eval* is false.
The problem is that the second eval gets (the actual + function 1 2
3) which invokes the right pathway
PS. The relevant part of Compiler.java is the emitValue method of
ObjExpr (or grep for readStringMethod -- I believe this is its only
use in the compiler).
On 30 January 2013 23:59, Michał Marczyk michal.marc...@gmail.com wrote:
On 30 January 2013 23:32, Chas Emerick c...@cemerick.com wrote:
As more and more projects are using edn format for config,
communication and etc, I think that default value of *read-eval*,
which is true, is source of vulnerability such as recently reported
ring issue [1].
And I don't understand why read-string depends on *read-eval* instead
of argument.
I
26 matches
Mail list logo
