>
> On May 9, 2012, at 12:15 PM, Michael Gardner wrote:
>
> > I've never understood why anyone would use prn/read for data transfer,
> > other than extreme laziness.
>
When I encounter the ancestor of XML in the mid 80s, SGML, it was used as a
typesetting tool for laser printers, just before
On May 9, 2012, at 12:15 PM, Michael Gardner wrote:
> I've never understood why anyone would use prn/read for data transfer, other
> than extreme laziness.
But extreme laziness is an excellent reason!
Larry Wall called laziness "the first great virtue of a programmer."
-Lee
--
You received
>> This is the point! On one hand I need to evaluate data from a client
>> on the other hand I'd like to filter out things like "rm -rf /", "drop
>> table users" etc. To me it looks like a contradiction impossible to
>> circumvent. So I ask if there's anything like "best practices" or even
>> bette
On May 9, 2012, at 11:01 AM, Rostislav Svoboda wrote:
> This is the point! On one hand I need to evaluate data from a client
> on the other hand I'd like to filter out things like "rm -rf /", "drop
> table users" etc. To me it looks like a contradiction impossible to
> circumvent. So I ask if ther
On Wed, May 9, 2012 at 5:01 PM, Rostislav Svoboda
wrote:
> On 9 May 2012 17:31, Tassilo Horn wrote:
>> you should bind *read-eval* to false when reading data from unknown sources.
>
> This is the point! On one hand I need to evaluate data from a client
> on the other hand I'd like to filter out t
On 9 May 2012 17:31, Tassilo Horn wrote:
> you should bind *read-eval* to false when reading data from unknown sources.
This is the point! On one hand I need to evaluate data from a client
on the other hand I'd like to filter out things like "rm -rf /", "drop
table users" etc. To me it looks like
Rostislav Svoboda writes:
> Many people just copy-paste code snippets to their source files/repl
> withouth really knowing if they are safe or not safe.
>
> IMO it might help to rename the *read-eval* to something like
> *read-eval-ACHTUNG-danger*. For me - as a newbie - it's a better
> proplem i
Rostislav Svoboda writes:
>> Simply don't `eval` code/data from sources you don't trust.
>
> In a client-server architecture the thing I (i.e. the server) don't
> trust is the client... and I'm not sure if I can ignore him just like
> that :)
Not evaluating everything a client sends you doesn't
On 9 May 2012 15:57, Walter Tetzner wrote:
> I feel like *read-eval* should default to false, and you should have to
> explicitly bind it to true. Either that, or there should be 'safe' versions
> of
Many people just copy-paste code snippets to their source files/repl
withouth really knowing if t
On 9 May 2012 15:35, Tassilo Horn wrote:
> Simply don't `eval` code/data from sources you don't trust.
In a client-server architecture the thing I (i.e. the server) don't
trust is the client... and I'm not sure if I can ignore him just like
that :)
Bost
--
You received this message because you
On May 9, 2012 10:02 AM, "Walter Tetzner"
wrote:
> I feel like `*read-eval*' should default to false, and you should have
> to explicitly bind it to true.
Yes, but with 'load' binding it to true. You are evalling anyway, and else
it would be quite difficult to use just when you need it.
--
Step
Walter Tetzner writes:
> On Wednesday, May 9, 2012 9:35:57 AM UTC-4, Tassilo Horn wrote:
>
>> I don't think code-as-data contributes to code injection
>> vulnerability, neither positively nor negatively. Simply don't
>> `eval` code/data from sources you don't trust.
>
> I think it does contribut
On Wednesday, May 9, 2012 9:35:57 AM UTC-4, Tassilo Horn wrote:
I don't think code-as-data contributes to code injection vulnerability,
neither positively nor negatively. Simply don't `eval` code/data from
sources you don't trust.
I think it does contribute through the reader. If y
On Wednesday, May 9, 2012 9:35:57 AM UTC-4, Tassilo Horn wrote:
> I don't think code-as-data contributes to code injection vulnerability,
> neither positively nor negatively. Simply don't `eval` code/data from
> sources you don't trust.
>
I think it does contribute through the reader. If you
Rostislav Svoboda writes:
> I think the topic 'code injection vulnerability' is never out of date
> especially if you treat data as a code. Unfortunately googling for -
> clojure code injection vulnerability - returns 'nil'.
>
> Any ideas? Comments? Opinions?
I don't think code-as-data contribu
On Wed, May 9, 2012 at 6:01 PM, Rostislav Svoboda
wrote:
> I think the topic 'code injection vulnerability' is never out of date
> especially if you treat data as a code.
> Unfortunately googling for - clojure code injection vulnerability -
> returns 'nil'.
>
> Any ideas? Comments? Opinions?
The
I think the topic 'code injection vulnerability' is never out of date
especially if you treat data as a code.
Unfortunately googling for - clojure code injection vulnerability -
returns 'nil'.
Any ideas? Comments? Opinions?
Bost
--
You received this message because you are subscribed to the Goo
17 matches
Mail list logo
