Yes, some very real problems are beginning to show. Its these that I’d like to discuss in detail.
- V8 – Its Fast. However, it doesn’t work well on a variety of architectures. Google also won’t commit to stability. Its cool handle technique permits management of scope on the stack. Of course, this means no C API and “Can you say HandleScope?”
- SpiderMonkey – Lots of features which the others don’t have, particularly “let,” “yield,” and E4X. However, until recently it was slow (to my knowledge, trunk builds are now on par with V8). Mozilla also won’t commit to regular unbundled releases. Works well on pretty much every architecture.
Module Loaders and Fragmentation
Module Loaders and Security
mysql = require(“mysql”);
… // Do your stuff
In the above example, the MySQL module can only connect to one database. Let’s look at the problems this alleviates:
- If your Apache server is misconfigured to allow text viewing of your source code, you have not given out any important security information.
- The lifespan of your passwords cannot be tracked by looking at your revision control (which also may be mis-configured for world-read).
- You could potentially create a sandbox database to run untrusted code in.
- You have a clean separation of configuration from code, and your language encourages this.
Thus, while CommonJS’s module specification includes an “export” object so that symbols are not exported by default, this does not go far enough to ensure that the symbols that are exported are properly sandboxed. The module framework should provide this.
Security and Private Pointers
- Code for multiple engines (though the application writers may have reason to care).
- Write modules for multiple module loaders.
- Re-implement sandboxing techniques on their own.
- Do type checking on every object to ensure that using a private pointer won’t crash the object.
As you may have guessed, I have some solutions to these problems. But for that you’ll have to wait for my next post…
* – V8 provides at least some help in this regard by insisting that you install private pointers into slots. However, this is an almost useless feature (as far as security is concerned) considering that almost every programmer puts their pointers into slot 0.