Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8E4EFE7D5 for ; Thu, 31 Jan 2013 15:28:12 +0000 (UTC) Received: (qmail 37172 invoked by uid 500); 31 Jan 2013 15:28:11 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 37137 invoked by uid 500); 31 Jan 2013 15:28:11 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 37128 invoked by uid 99); 31 Jan 2013 15:28:11 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 15:28:11 +0000 Received: from localhost (HELO mail-vb0-f45.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jan 2013 15:28:10 +0000 Received: by mail-vb0-f45.google.com with SMTP id p1so1808529vbi.18 for ; Thu, 31 Jan 2013 07:28:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.74.38 with SMTP id q6mr7553666vdv.17.1359646089789; Thu, 31 Jan 2013 07:28:09 -0800 (PST) Received: by 10.52.68.209 with HTTP; Thu, 31 Jan 2013 07:28:09 -0800 (PST) In-Reply-To: References: <5102B439.10500@lymegreen.co.uk> <8A160546-A117-48CE-94B5-3CAC66EDE3ED@apache.org> Date: Thu, 31 Jan 2013 15:28:09 +0000 Message-ID: Subject: Re: Branch to switch from SpiderMonkey to Node.js From: Robert Newson To: "dev@couchdb.apache.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Well, I think we can assert sandboxedness against JSAPI and V8 indirectly by verifying that neither provides features like file and socket I/O. If we also hook couchdb up to something that is capable of these things, then an engine-specific test suite has to be made to verify that they've been blocked. I tried tackling this for the erlang view server, if you recall, by walking the AST of the erlang code, and ensuring no calls were made to the file module (etc). On 31 January 2013 15:24, Jan Lehnardt wrote: > > On Jan 31, 2013, at 16:20 , Robert Newson wrote: > >> Part of the difficulty in asserting the correctness of the sandbox is >> that important tests like "cannot read file", "cannot write file", >> "cannot open socket" cannot be written against SpiderMonkey (or, >> presumably, V8) as they simply don't provide those features. Node >> does, and that's the principal advantage of it over V8 as I understand >> things, but it is obviously silly to write a test suite on that basis. > > Excellent point. What ways of mitigating to we have? > > Can we construct a sandbox that only allows calling of functions that > we specify (has Jason done this?). > > > Best > Jan > -- > >> >> B. >> >> On 31 January 2013 15:17, Jan Lehnardt wrote: >>> >>> On Jan 31, 2013, at 15:52 , Benoit Chesneau wrote= : >>> >>>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith wrote= : >>>> >>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis >>>>> wrote: >>>>> >>>>>> >>>>>> That whole process sounds like not a lot of fun. >>>>>> >>>>> >>>>> Right. That is kind of my point. CouchDB is a JavaScript thing, and >>>>> nowadays people have a very well-adopted and well-understood JavaScri= pt >>>>> engine on their computers. Maybe it should just use that. >>>>> >>>>> >>>>> >>>> couchdb is not a javascript thing, This is a database in which one and= the >>>> default engine for M/R is using the language javascript. >>>> >>>> Not all developers have nodejs installed. None of my servers have it. >>> >>> The question is not if you server have it, but whether you could instal= l a >>> compatible version easily. >>> >>> I=92d love to hear if you or others are not covered by >>> >>> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-m= anager >>> >>> >>>> A,d >>>> I'm not alone in that case. Imo we don't take the problem at the right >>>> angle. Note that I'm fine to have eventually a nodejs view server aro= und >>>> if it's needed, that not the question. >>>> >>>> Which problems are we trying to solve ? >>>> >>>> - problem with the spidermonkey distribution. There are many versions >>>> deployed on different OS/distributions. Even some that aren't packaged= by >>>> mozilla >>>> - having more concurrency for couchapps and view indexation >>> >>> I=92d say this is irrelephant to the view engine. The idea here is that= a >>> Node view engine is much more likely to see progress towards that goal >>> though as it comes with an enthusiastic community that shares the inter= est >>> of having an awesome CouchDB Server (via NPM). NPM is effectively a Cou= chApp >>> >>> >>>> I would add a third one: beeing able to distribute couchdb with a vie= w >>>> engine that work on mobile platform or that eases the distribution on = the >>>> mobile. But this isn't the main problem and not the one we are all try= ing >>>> to solve if I understood well. >>> >>> Not a bad point, but also out of scope for this discussion, I=92d say. = Either >>> way, bot engines have been ported (SM) or designed (V8) to also run on = mobile. >>> That doesn=92t mean all is equal, but the basics for this are there. >>> >>> >>>> Imo one of these problems can be solved by improving the view protocol= e. I >>>> think we could work on a new protocole. And while we are here really >>>> document the current one as a specification in text. >>> >>> We have seen zero evolution of the view protocol in the past. My hope i= s >>> that with a wider target audience (node folks), we=92ll finally get >>> contributions there. >>> >>> >>>> The second, need some discussions. I'm with randall, I think that port= ing >>>> couchjs to v8 is not that hard and would really solve the problem. Non= e of >>>> the distributions have the same of nodejs also there is still the >>>> sandboxing to fix. And it seems really weird to remove I/O on nodejs. >>>> Things that make the difference between nodejs and v8. Having commonjs= is >>>> another thing. One advantage of v8 vs spidermonkey is that we can embe= d it >>>> in our code. the license allows. Also building v8 is a way easier comp= ared >>>> to spidermonkey. >>>> >>>> If we are all agree on these two problem let's try to do some action o= n >>>> them and first we shoudl collect all the current feature we have and t= hat >>>> we don't want to lost, then start to find solution to handle them and = fix >>>> the issues we have. >>>> >>>> Thoughts? >>> >>> I really like the idea of throwing away all that C code (and gain JS co= de >>> instead). >>> >>> And I like that Jason did demonstrate that it is feasible. >>> >>> Two things remain: >>> >>> 1. Show that sandboxing is sufficient for our needs >>> - can we come up with JS code that is supposed to fail and then make= sure it does? >>> >>> 2. Show that the Node view server works on commonly distributed Node ve= rsions. >>> - if, say Node 0.6 is widely supported on the Latest-1 Ubuntu releas= e (just for the >>> sake of argument) we should make sure it is compatible. >>> - Can you all help collecting the minimally available Node versions = for systems that >>> we intend to support with master? >>> >>> Cheers >>> Jan >>> -- >>> >