> So yes, Elixir please! :) And if we get a sandbox as well, we can even enable it by default :)
I tried to add a .beam produced by Elixir to my CouchDB installation (I didn't want to rebuild the whole project), but Couch can't find it. I posted a question on this ML[1]. Any hints? [1]: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201308.mbox/%3ccaapy6eptsvstpywvqurnnxn0pwbfwmitee2gawjsphatv5i...@mail.gmail.com%3E On Thu, Oct 17, 2013 at 12:29 AM, Jan Lehnardt <[email protected]> wrote: > > On Oct 16, 2013, at 23:16 , Benoit Chesneau <[email protected]> wrote: > > > On Wed, Oct 16, 2013 at 10:54 PM, Filippo Fadda < > > [email protected]> wrote: > > > >> Sandboxing is something optional I think, you need only when you are > >> developing a CouchApp, when you do all in JavaScript, using the _users > >> database and running the app inside CouchDB. But if you are just using > >> CouchDB like a database, developing a web app using PHP or Python, for > >> example, you'll never give access to CouchDB from outside, through Futon > >> for example, so no one will be able to store a new design doc in your > >> database to run malicious code. I'm using PHP with the ElephantOnCouch > >> Query Server, writing ddoc in PHP, and I really don't see why I should > >> using runkit to sandboxing the Query Server. > >> > >> -Filippo > >> > > > > Sandboxing is not only needed for couchapps but also views. If someone > > using a view inspect your hd and emit the result or send your docs > using > > a tcp connections to an unknown remote target it can be a risk. That's > why > > it's needed. Even allowed users can be a possible risk. > > I think Filippo used “CouchApps” as a synonym for “you may receive code > not written by you or someone your trust” in which case you absolutely > want a sandbox. > > My point was just that there are equally scenarios where that trust exists > and Filippo illustrated them a bit better than I did originally. > > So yes, Elixir please! :) And if we get a sandbox as well, we can even > enable it by default :) > > Best > Jan > -- > > > > > > > > > > > >> > >> On Oct 16, 2013, at 10:27 PM, Jan Lehnardt wrote: > >> > >>> Another option would be to start with treating the Elexir Query Server > >>> like the Erlang Query Server and keep it off by default and with full > >>> access to the internals, so people could opt into it, if their > >> environment > >>> allows for it. > >>> > >>> Sandboxing could be a step on top or later. > >>> > >>> I for one would like to see native Elexir support for Views et.al in > >> CouchDB :) > >>> > >>> Best > >>> Jan > >>> -- > >>> > >>> On Oct 16, 2013, at 20:48 , Paul Davis <[email protected]> > >> wrote: > >>> > >>>> There have been discussions on figuring out how to sandbox Erlang. The > >>>> biggest thing on that front was that we'd want it to be a whitelist as > >>>> opposed to a blacklist of modules and/or module/function pairs. The > >>>> second is that with dynamic invocation its not immediately apparent if > >>>> that's entirely possible to do. > >>>> > >>>> On Wed, Oct 16, 2013 at 10:39 AM, Chris Keele <[email protected]> > >> wrote: > >>>>> Hey everyone! I'm trying to develop a sandbox for Elixir, and I > wanted > >> to see how such a library might prove useful to the CouchDB dev > community. > >>>>> > >>>>> My initial goal is just to be able to run string of code in a > >> predefined environment with configurable modules disabled, returning all > >> output. But I'd like to design it for bigger things from the ground up, > so > >> I was wondering what sorts of requirements you might have of a sandbox > >> library if you wanted to, say, implement a secure view processor. > >>>>> > >>>>> I've started a discussion thread here: > >> https://groups.google.com/forum/#!topic/elixir-lang-talk/wA1l74HCZmI, > but > >> I'm particularly interested in your opinions! > >>>>> -- > >>>>> Chris Keele > >>>>> > >>> > >> > >> > > -- Best regards Alexei Sholik
