Russell, thanks for you comments on the ticket. For the record, I fixed some i/o bugs in couchjs and most of the test suite is passing on my branch now. I have nearly achieved phase 1.
I think you probably agree, in a situation like this, the only acceptable approach is the whitelist. I think it might be easy to disable i/o in Node.js, because it is easy to control what is in scope for the guest code. Without access to require() or the fs module, how can code perform i/o? Note, since the stakes are high, we must *confirm* this hypothesis, of course. An interesting exception and challenge for the "no I/O" rule is that of course the entire implementation of view servers is via message passing over stdio. I agree with your comments about npm. Three points: 1. Right, it is inappropriate or out of scope to talk about using modules/packages/npm from the view server. Besides huge security issues, it is only marginally useful within the CouchDB 1.x API. So much of the API is stateless and pure-functional programming. 2. One reason I want to try Node.js (rather than V8) is to open the door to users extending CouchDB and/or building applications with full-on arbitrary Node.js code--totally separate from the view server API: maybe a version 2.x discussion. 3. Besides security, if someone could demonstrate a great performance gain by e.g. embedding V8 in Erlang then that would be a strong argument against Node.js. I am not holding my breath. We could extend the view server protocol to "upgrade" from stdio to SysV or POSIX shared memory and get a similar performance boost. The Erlang side would be a NIF and the Node side would be a native module--so, C code talking to C code. On Fri, Jan 25, 2013 at 9:38 PM, Russell Branca <[email protected]>wrote: > Getting a spec together is a good next step, I'll update COUCHDB-1643 with > some ideas. > > One distinction that would be useful, is what functionality is needed in > the view engine for just map/reduce, versus user defined functionality in > filters/validate/update/show/lists. I'm intrigued by the idea of a fast DSL > on top of Erlang for views, and then making it easy to have node.js > applications for the rest of the pieces, and keeping those separate. > > > -Russell > > > On Fri, Jan 25, 2013 at 12:13 PM, Jason Smith <[email protected]> wrote: > > > Wow, thanks for so much feedback, Russell! > > > > Unfortunately, libmozjs185 is also "a make away" I think. > > > > The V8 vs. Node discussion is premature until we clearly define the > > requirements. What exactly is this "sandbox"? What guarantees or > invariants > > does it ensure? I have proposed a specific feature list in COUCHDB-1643. > > > > Without a spec, we sound like this: > > > > Salviati: I cut three thousand lines of code and kept 100% compatibility. > > Simplicio: Yes, but your implementation does not have a "sand box." > > Salviati: What is a "sand box"? > > Simplicio: A "sand box" is that which V8 can provide, but which Node.js > > cannot. > > Salviati: But you can write Node modules in C which call the V8 API. > So... > > Simplicio: Sandbox! > > Salviati: But-- > > Simplicio: SANDBOX! > > > > > > > > On Sat, Jan 26, 2013 at 2:27 AM, Russell Branca <[email protected] > > >wrote: > > > > > Both Node.js and V8 are a make away, so the question is what else each > > > brings to the table. > > > > > > I'm of the opinion that the big win of Node.js is npm. I would love to > > see > > > CouchDB extensible by npm modules. I've done some experiments along > those > > > lines, but the problem comes back to sandboxing. As you pointed out > > Jason, > > > CouchDB's javascript security has not been an issue, because the > > > SpiderMonkey sandbox is solid. Hopefully someone with deeper knowledge > of > > > Node.js than myself will prove me wrong, but I haven't found a way to > > > securely sandbox it and still allow the use of require for npm modules. > > > > > > Couple of alternative ideas: > > > > > > Option F: Distinguish between core "database" level functionality and > > > "application" level logic. > > > > > > - The internal view engine needs to be simple, efficient and secure. > Have > > > this use V8 directly or a DSL on top of Erlang. > > > - Abstract CouchApp level logic from the core view engine. Things like > > list > > > and show functions are perfect for Node.js and npm. I would love to see > > > this extended further to make it even easier to create user defined > > > functionality. There are so many common patterns, like the user > > > registration thread that popped up yesterday, where the current > approach > > is > > > to build a little external service, that in my opinion would be better > > > served by a more capable CouchApp engine. I'm not saying we should try > > and > > > replace all potential application level logic, but at the very least > add > > in > > > a concept of a "worker" functions that can filter on different event > > types > > > (new user, new doc, updated doc, failed validation function, etc etc) > and > > > execute some user defined function. > > > > > > There are admittedly problems with this approach. Where do filters, > > > validation functions and update handlers go? This would also require > > > depending on both V8 and Node.js, which I think is not as big of a > > problem > > > if the CouchApp engine is structured in a way to be replaceable with > > other > > > implementations. > > > > > > Option G: Make all user defined functionality execute in an isolated > > > context using a remote protocol, and basically turn it into a remote > > > service. This would make it even easier to build custom engines, but > has > > > some interesting properties like allowing you to have the engine > running > > on > > > a separate server. Or fun stuff like spinning up a larger EC2 instance > > when > > > you need to rebuild a view, and then rolling back down when the full > view > > > build is done. > > > > > > Option H: Build something like JInterface for Javascript, creating a > > stand > > > alone Javascript node and switching over to message passing for all the > > > jobs. This has some interesting properties for bulk and parallel view > > > builds. > > > > > > > > > I'm glad to see this conversation coming along. Jason, cool stuff, > thanks > > > for taking the initiative on this! > > > > > > > > > -Russell > > > > > > > > > On Fri, Jan 25, 2013 at 10:01 AM, Jason Smith <[email protected]> > wrote: > > > > > > > Hi, David. Yes, you make very good points. I even think you (and > > Benoit) > > > > may be ultimately correct > > > > > > > > I dispute that Node.js is V8. Node is not V8. Node.js is a direct > link > > to > > > > God. When I pray to God in the JavaScript language, God moves > electrons > > > > around inside my computer. He writes files to my disk, and He sends > > > packets > > > > out my Ethernet cable. > > > > > > > > A thought experiment: Find some computer power users or sysadmins. > > Break > > > > them into two groups, with one task each: > > > > > > > > 1. "Install Node.js on your computer, by any means" > > > > 2. "Install V8 on your computer, by any means" > > > > > > > > Which group would self-report more success? Which group would > register > > > more > > > > frustration? > > > > > > > > That is the sort of question I hope to answer (or at least supply > some > > > > data). With any luck I can falsify my theory and theology. > > > > > > > > > > > > On Fri, Jan 25, 2013 at 11:35 PM, david martin < > > > > [email protected] > > > > > wrote: > > > > > > > > > On 25/01/13 11:18, Jason Smith wrote: > > > > > > > > > >> My **tentative** position is that V8 is a waste of time. We should > > use > > > > >> Node.js, not V8. In other words, we should not change couchjs to > > link > > > > >> against libv8.so instead of libmozjs.so. Instead, we should > > **remove** > > > > the > > > > >> couchjs binary and build a 100% compatible node version. Again, > this > > > is > > > > my > > > > >> *suspicion* but I want to explore it more. > > > > >> > > > > >> Embedding V8 is, roughly, the same work as embedding SpiderMonkey. > > It > > > > does > > > > >> not change much. We still depend on an obscure VM with a quirky > > build > > > > >> system. > > > > >> > > > > > According to Wiki > > > > > > > > > > "Node.js is a packaged compilation of Google's V8 JavaScript > engine, > > > the > > > > > libUV platform > > > > > abstraction layer, and a core library, which is itself primarily > > > written > > > > > in JavaScript." > > > > > > > > > > "We still depend on an obscure VM ( so V8 is an obscure VM although > > it > > > is > > > > > embedded in Node.js ) with a quirky build system." > > > > > > > > > > Get rid of all quirky build systems, use rebar which builds > > everything > > > > AND > > > > > produces an installable relocatable executable package containing > > > Erlang > > > > VM > > > > > and V8 VM and C routines as NIF's where required for speed. > > > > > > > > > > So Node "is" V8 plus a lot more which is not required > > > > > > > > > > > > > > > -- > > > > > David Martin > > > > > > > > > > > > > > > > > > > > > > -- > > > > Iris Couch > > > > > > > > > > > > > > > -- > > Iris Couch > > > -- Iris Couch
