Re: Security implications of code is data/data is code

Just joking :) There are a bunch of "golden rules" that violate on a regular basis for good reasons. With some satisfaction I have to confess. When you have a muti purpose tool in your hands that you can bend to almost any use it's hard to be restrained by taboos :) Luc P. > Sorry Luc P.,

Re: Security implications of code is data/data is code

Sorry Luc P., you are right. I meant that people wouldn't do that without a good reason, but it was not what I wrote. On Wednesday, January 22, 2014 3:10:27 AM UTC-2, Luc wrote: > > Your last statement is incomplete. > > It all depends on trust. We do eval at > runtime of code and data w/o edn

Re: Security implications of code is data/data is code

I would go one step further and say that homoiconicity actually is an improvement. There are a dozen ways to shell out in ruby. The syntax is more complex on a number of fronts. Cleansing user input in Clojure is simpler. Clojure's regularity makes it much simpler to cleanse. In addition: the j

Re: Security implications of code is data/data is code

I don't think homoiconicity is the issue, except in a very indirect way. Note that Common Lisp does have a rather annoying, insecure default that did allow the kind of attack you're talking about: *read-eval* defaults to T , which enables the #. reader macro

Re: Security implications of code is data/data is code

Your last statement is incomplete. It all depends on trust. We do eval at runtime of code and data w/o edn but we know it comes from a secured source. Doing such thing from an unsecured alien source would "potentially" look insane. Lets not presume about the insanity of the designer w/o some dee

Re: Security implications of code is data/data is code

Not every input is through the reader. For instance, Integer.parse takes a string argument and returns a java object. So there's no security problem there, unless it's a problem with the Integer class itself. Another piece of the puzzle, Clojure needs a way to represent objects and code as data.

Re: Security implications of code is data/data is code

Hi Daniel, I'm not an expert in security but AFAIK this is not a problem. Every user input is a string and you chose how to parse it. There is a edn reader that is safe, but you can use specific parsers depending on the input. Of course if you read and eval the string anything could happen, but