On Fri, Jan 13, 2012 at 6:47 PM, Anthony Grimes <disciplera...@gmail.com> wrote: > Clojail errs on the side of safety and not on the side of "Oh, well maybe he > wasn't trying to break the sandbox. Let's allow it anyway.". Treating macros > as opaque is just another hole in what is already difficult sandboxing. > Macros are not even remotely close to functions. They *create* code. That > code, just like any other explicitly written in your application, needs to > be sandboxed. It is much easier and safer to sandbox dangerous functions. > The fact that expanded macro code that uses those functions is also affected > is less of a bug and more of a feature.
You seem to be confused. We were discussing 4Clojure's rules, where the stakes are at worst letting a person "cheat" slightly, not a server security system or something, where the stakes would be allowing hacking of some sort. Your concern is immensely out of proportion to the consequences of someone cheating at 4Clojure's learning game. > That said, of course it is unfortunate that things like this occur in > 4Clojure for things as simple as for. But clojail and 4clojure are separate > projects. clojail is focused on being as safe as possible, which may > sometimes clash with what would be most convenient in 4Clojure. Unclear here is what the two have to do with one another. There's no obvious relevance of clojail's requirements for 4Clojure. Indeed, as you seem to have realized, the requirements are distinct and sometimes would conflict. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
