[MIR] mongodb, libv8, snowball, gyp

[James Page]

>> mongodb <<

Availability:

In universe for several releases.

Rationale:

Preferred data storage platform for Ceilometer (core OpenStack project) and a key component juju-core.

Security:

Two security issues, both resolved upstream. native helper security issue only impacts earlier versions of MongoDB - 2.4.x uses libv8 instead of spidermonkey and does not have this function.

QA:

Works out-of-the-box from packaging.
Package ships a test suite (smoke) which is executed on all target platforms.
Generally well maintained in Debian and in Ubuntu (server team).
Issue with OpenSSL license compatibility needs to be resolved (upstream working on this).

Dependencies: All in main aside from libv8, snowball and gyp

Maintenance:

Upstream push out minor point releases for bug fixes (MRE will be applied for).
Packaging generally in good shape aside from static linking of client binaries (being worked on in Debian).

>> libv8 <<

Availability:

In universe for several releases.

Rationale:

Dependency for MongoDB embedded scripting engine.

Security:

Lots of CVE's:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=v8

I suspect that alot of these relate to the use of v8 in Chrome. However as this is a core component of chrome, we can reasonably expect Google to be responsive to security issues in the future.

QA:

Package works.
Regression tests executed during package build.

Dependencies:

Use gyp for build system.

Maintenance:

Well maintained in Debian (supports nodejs as well).

>> gyp <<

Availability:

In universe.

Rationale:

Build dependency for libv8

Security:
No CVE's found

QA:
Works from packaging, test suite present but not executed during build.

Dependencies: All in main

Maintenance:

Until recently not that well maintained in Debian; however nodejs maintainer seems to be picking things up now (see version in saucy which refreshed the package considerably).

>> snowball <<

Availability:

In universe.

Rationale:

libstemmer is a build and runtime dependency for mongodb > 2.4

Security:

No CVE's found

QA:

Packaging generally looks good - multi-arched.
Unit test suite executed during package build process.

Dependencies:

All in main.

Maintenance:

Debian and Ubuntu hold a pre-release snapshot; not much activity in the last 18 months.

Background information:

libstemmer provides algorithmic stemmer functions for building natural language search functions.

[Michael Terry (mterry)]

Didier, can you look at this set?

[Didier Roche-Tolomelli (didrocks)]

I would prefer setting that on jdstrand's plate, as supporting V8 is not on the plan for the security team AFAIK, so before looking at this MIR, let's get his opinion :)

[Jamie Strandboge (jdstrand)]

libv8 is something we've considered in the past as part of our webkit work and Ubuntu SDK audits. We can't effectively support libv8 because it is constantly changing. Therefore, backporting patches becomes infeasible very quickly and we are faced with having to use a new upstream release-- which would likely break anything that depends on it. NAK on libv8 in the archive.

What we did for the Ubuntu SDK is allow an embedded version of libv8-- this is guaranteed to always match with its consumer, but for this to work it must be demonstrated that libv8 does not process untrusted javascript. If it doesn't, there is no attack surface for the embedded libv8 and therefore it doesn't have to be kept up to date. If it does processed untrusted javascript, NAK.

[Jamie Strandboge (jdstrand)]

"NAK on libv8 in the archive" should have read as "NAK on the libv8 in the archive moving to main".

[James Page (james-page)]

Hi Jamie

On 28/06/13 12:32, Jamie Strandboge wrote:
> libv8 is something we've considered in the past as part of our webkit
> work and Ubuntu SDK audits. We can't effectively support libv8 because
> it is constantly changing. Therefore, backporting patches becomes
> infeasible very quickly and we are faced with having to use a new
> upstream release-- which would likely break anything that depends on it.
> NAK on libv8 in the archive.

OK - sounds entirely reasonable and this was something I was concerned
about.

> What we did for the Ubuntu SDK is allow an embedded version of libv8--
> this is guaranteed to always match with its consumer, but for this to
> work it must be demonstrated that libv8 does not process untrusted
> javascript. If it doesn't, there is no attack surface for the embedded
> libv8 and therefore it doesn't have to be kept up to date. If it does
> processed untrusted javascript, NAK.

mongodb ships an embedded version of libv8 within the upstream tarball;
we can switch back to using this so that we avoid libv8 being a
standalone library.

Re: it must be demonstrated that libv8 does not process untrusted javascript

libv8 is used to provide the scriptable shell in mongodb; access to the
shell is via the mongo client application. By default, authentication
is turned off in the packaging - so its possible to access the db and
setup authentication - see
http://docs.mongodb.org/manual/tutorial/enable-authentication/. That
said the default bind ip is 127.0.0.1 so only users with access to the
system running mongod have unauthenticated access to the database -
allowing a configuration to be bootstrapped securely.

Hopefully that clarifies use of v8 sufficiently to support embedded
inclusion in mongodb.

--
James Page
Ubuntu Core Developer
Debian Maintainer
<email address hidden>

[Jamie Strandboge (jdstrand)]

"Re: it must be demonstrated that libv8 does not process untrusted javascript

libv8 is used to provide the scriptable shell in mongodb; access to the
shell is via the mongo client application."

We allowed V8 to be embedded in the Ubuntu SDK because the attack surface was greatly reduced-- it won't process arbitrary QML-- it will process code from the developer. There are some corner cases with string processing where we need to keep an eye on V8 CVEs, but on the whole, V8 in the Ubuntu SDK can largely be ignored.

For mongodb you described a different situation. The mongo client application provides a scriptable shell. We fixed all kinds of vulnerabilities for an authenticated attacker in other software. Even if we said we need to enforce authentication and decided we wouldn't fix V8 bugs for an authenticated attacker, we would still have to fix them for the now non-default configurations that don't use authentication and/or connections through the loopback (loopback isn't strong protection anyway-- if there were a vulnerability in another piece of software on the system, a remote attacker could attack it and then attack mongo via the loopback)
I think this provides an attack surface such that we would have to support V8 with security updates.

[Jamie Strandboge (jdstrand)]

I accidentally clicked 'Post comment' before I was ready....

I think this provides an attack surface such that we would have to support V8 with security updates. This very likely means full version upgrades for mongodb to support new versions of V8 because V8 may change so much (assuming that upstream mongodb stays on top of V8 security issues in the first place).

[James Page (james-page)]

Upstream mongodb have definitely backported some fixes to their embedded 10gen version; however I will need to get a more definitive response on how 10gen manage security issues in dependencies such as this.

FWIW I was intending on applying for a MRE for MongoDB assuming successful MIR.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.