On Mon, Jul 6, 2009 at 1:43 AM, Richard Hirsch <[email protected]>wrote:
> Should I deploy with this functionality active or not? I wouldn't. It's kinda like taping a "Hack Me" sticker onto the site. :-) > > > I just did a stax deplyoment with the > actions.scala_interpreter.enable=false > > D. > > On Mon, Jul 6, 2009 at 10:24 AM, Vassil Dichev<[email protected]> wrote: > >> Should we remove it completely from the source or should we just > >> deactivate it by default? > >> > >> I agree that I wouldn't activate it in a producticve setting but it > >> might be useful while developing. > > > > Granted, this might not be the best way to monitor/debug ESME (e.g. if > > memory is so tight the JVM won't be able to create a new interpreter > > instance or send a new message). When I implemented the feature I was > > actually thinking of Dick's request for making it easier for ESME > > newcomers to learn Scala. I've also spent some time thinking about > > using ESME in a university and this feature makes a lot of sense in a > > classroom. > > > > My point is, I still think it could be made secure with a careful > > java.policy file (which a conscientious administrator should use > > anyway). David, do you think the Scala interpreter is impossible to > > secure or just not worth the effort? Also, what difference would it > > make to use Rhino, but not Scala in terms of a secure interpreter? The > > Scala interpreter implementation does use a new classloader and even > > allows you to override it and implement your own one. Try e.g. "import > > org.apache.esme.model.Message" or "import net.liftweb.util.Box". > > > > If the primary concern is trust in a federation, we could make it so a > > server is not allowed to participate in a federation if the Scala > > interpreter action is enabled. > > > > Cheers, > > Vassil > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp
