[GitHub] wohali commented on issue #1333: Support for modern Spidermonkey versions?

[GitBox <gi...@apache.org>]

wohali commented on issue #1333: Support for modern Spidermonkey versions?
URL: https://github.com/apache/couchdb/issues/1333#issuecomment-390282102
 
 
   Hi @browndav ,
   
   1. Sadly, there is no way to build CouchDB's `couchjs` binary against any newer version of SpiderMonkey. There are a number of reasons, but the most compelling is that the current specification of a design document map / reduce function as a bare `function () {...}` is [no longer syntactically valid any modern JavaScript engine](https://issues.apache.org/jira/browse/COUCHDB-1643).
   
   To move to a newer version, we must either deprecate the current design document syntax, or auto-transform/auto-wrap JS functions within it. The problem with the latter approach is that a small percentage of users have stuck other stuff ahead of the function declaration in their `map` / `reduce` / etc. functions, such as variable declarations or library imports, that would break with a simple auto-rewrite wrapper.
   
   With the very next release of CouchDB binaries, Apache CouchDB will be supplying pre-built SM1.8.5 binaries via our own open build chain. This is to ensure that the most popular platforms (Debian, Ubuntu, CentOS, RedHat, Windows, docker) have the library built with the right options. This is motivated by recent distributions dropping support for SM1.8.5, or changing build-time options such that instability is introduced.
   
   There was an [experimental Node-based replacement](https://issues.apache.org/jira/browse/COUCHDB-1894) for the SM 1.8.5 view server in 1.x, but the "extreme sandboxing" we accomplish with Spidermonkey is not there, meaning that the Node-based viewserver is a gaping security hole, and violates the view server specification (no side effects are allowed!) As such we can't recommend you use it anywhere. The effort is abandoned.
   
   The current plan **forward** is two-fold.
   
   First, the team is working as hard as possible on improving [mango](http://docs.couchdb.org/en/2.1.1/api/database/find.html), the in-built declarative solution, to provide coverage of as many boilerplate secondary indexes as possible. Foremost, Mango is inherently faster than any external query server can ever be. This reduces the need for JavaScript overall. Users can also add the dreyfus / clouseau add-on from Cloudant to enable Lucene-powered full-text search as another kind of secondary index.
   
   Second, we've had (thanks to @dmunch) initial good experiences with the [Microsoft ChakraCore engine](https://github.com/microsoft/ChakraCore). Unlike V8/Node, ChakraCore is lightweight, small, and intended to be embedded in other systems directly. Microsoft's own Cosmos DB (formerly Document DB) was inspired by Apache CouchDB, and uses ChakraCore extensively as its JS engine, as does the new Edge browser.
   
   @dmunch's [experimental ChakraCore-based query server](https://github.com/dmunch/couch-chakra) already solves both the sandboxing and the anonymous function concerns, and has a number of other exciting features as well. It is also compatibly licensed (ALv2.0) as is ChakraCore itself (MIT).
   
   Such a major change - swapping out SM1.8.5 - that induces any sort of backwards incompatibility can't occur until a major version release, so the earliest I'd expect to see anything like this in CouchDB would be the 3.0 release. If we can solve the remaining TODOs for the couch-chakra solution, we could drop it in sooner (maybe 2.3.0). We'd welcome any help you might be able to give us on this!
   
   2. Yes, we keep tabs on the MITRE CVEs for vulnerabilities. We also welcome any security reports at our (security email address)[security@couchdb.apache.org]. Because of the aforementioned sandboxing, and the fact that couchjs wraps SM1.8.5 in a very constrained environment, the very large proportion of exploits possible with a JS engine are effectively mitigated.
   
   For bookkeeping, I'm going to close this ticket out and open forward-looking tickets that make more sense for our plans, but I'm happy to continue this discussion here or in those tickets.
   
   Can I ask - other than being successful deploying SM1.8.5 easily, are there any other concerns you or your team have? For instance, are you writing complex JS views that require newer ECMAScript functionality? Or are you trying to achieve something else with a view?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services