couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 15:28:09 GMT
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 <jan@apache.org> wrote:
>
> On Jan 31, 2013, at 16:20 , Robert Newson <rnewson@apache.org> 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 <jan@apache.org> wrote:
>>>
>>> On Jan 31, 2013, at 15:52 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>>>
>>>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <jhs@iriscouch.com> wrote:
>>>>
>>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <paul.joseph.davis@gmail.com
>>>>>> 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 JavaScript
>>>>> 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 install a
>>> compatible version easily.
>>>
>>> I’d love to hear if you or others are not covered by
>>>
>>>    https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
>>>
>>>
>>>> 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 around
>>>> 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’d 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 interest
>>> of having an awesome CouchDB Server (via NPM). NPM is effectively a CouchApp
>>>
>>>
>>>> I would add a third one:  beeing able to distribute couchdb with a view
>>>> 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 trying
>>>> to solve if I understood well.
>>>
>>> Not a bad point, but also out of scope for this discussion, I’d say. Either
>>> way, bot engines have been ported (SM) or designed (V8) to also run on mobile.
>>> That doesn’t mean all is equal, but the basics for this are there.
>>>
>>>
>>>> Imo one of these problems can be solved by improving the view protocole.
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 is
>>> that with a wider target audience (node folks), we’ll finally get
>>> contributions there.
>>>
>>>
>>>> The second, need some discussions. I'm with randall, I think that porting
>>>> couchjs to v8 is not that hard and would really solve the problem. None 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 embed it
>>>> in our code. the license allows. Also building v8 is a way easier compared
>>>> to spidermonkey.
>>>>
>>>> If we are all agree on these two problem let's try to do some action on
>>>> them and first we shoudl collect all the current feature we have and that
>>>> 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 code
>>> 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 versions.
>>>    - if, say Node 0.6 is widely supported on the Latest-1 Ubuntu release (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
>>> --
>>>
>

Mime
View raw message