Two Bare releases landed in September, and both are a meaningful step in making Bare safer to embed next to code you don't fully trust, like plugins, extensions or user scripts:
- Bare v1.33.0 adds a seal for native code and a written threat model.
- Bare v1.33.0 brings bare-module v7.0.0 to Bare along with a new embedder context
Seal the door to native code
In Bare, native addons can read files, open sockets and start programs - whoever can load addons can do virtually anything.
Bare v1.33.0 adds Bare.Addon.seal() (bare_seal() from C, for apps that embed Bare). Load the addons your app needs and seal, and Bare won't bring any new native code into the process. Addons that are already loaded or compiled into the binary stay available, and trying to load anything else throws. The seal covers every thread, including ones started later, and it can't be undone.
Bash / Shell
// 1. Load the native addons you trust
// 2. Freeze the set
Bare.Addon.seal()
// 3. Run code you don't fully trust. New addons can no longer load.Think of a Bare process as a fishing boat, and native addons as its gear: nets, rods, winches and sonar. Before leaving port, the skipper (the embedder) loads the gear they trust. Casting off is the seal: for the rest of the trip, no new gear comes aboard. The deckhands (the code you don't fully trust) can use any gear on deck, and can fish only the waters on the charts they were given (the module protocol). Casting off doesn't fix a leaky hull, though, so the boat still needs a sound one: an OS sandbox
One Bare process, before and after the seal.
A threat model, in writing
Bare now ships a threat model that spells out what Bare promises, what it doesn't, and what counts as a security bug. The short version for embedders:
- The seal freezes your set of addons, it doesn't make that set safe. Every addon you load before sealing is available to all code in the process, so choose deliberately.
- Seal before any untrusted code runs.
- Seal every Bare process you start.
- The seal can't stop memory bugs. If you run untrusted JavaScript, an OS-level sandbox is required. This is not optional.
bare-module v7.0.0: modules read only what you hand them
Bare v1.33.0 ships bare-module v7.0.0, which puts the threat model into effect. The module system no longer has file-system access on its own. It reads only through the protocol the embedder passes in. You can load untrusted code with a restricted protocol, and it will only be able to reach what that protocol reaches. The bare CLI passes in its own file-system protocol, so it can still read from disk.
Breaking changes
bare-module v7 is a breaking change: Module.load() and Module.resolve() now return promises. You can use Module.loadSync() and Module.resolveSync() for synchronous code.
You can learn more about the ModuleLoader and the protocol API in the bare-module reference docs.
New embedder context API
Some addons need handles only the host app can provide, like the Java VM on Android. Bare v1.33.0 adds an embedder context API for this:
- The embedder publishes those handles under agreed keys.
- The addons look them up.
On Android, Bare Kit publishes the Java VM this way from v2.5.0.
Every addon in the process can read a published handle, and the registry freezes along with the seal, so publish only what's needed, and publish it up front. You can learn more about the calls and the keys in use in the embedder context API reference docs.
Also in these releases
Hardened runtime bindings, and safer handling of uncaughtException and unhandledRejection listeners that throw.
Full details are in the release notes for v1.32.0 and v1.33.0, and in the Bare release overview.
Embed it, seal it , ship it.
npm i -g bare
Run bare -v to check you're on 1.33 or later. Bare.Addon.seal() and Bare.Addon.sealed are documented in the Bare runtime API reference.
Show us what you've got
Running untrusted code on Bare? Join the Pear Development group on Keet and tell us what you're building:
keet.io/chat/#yfo6dbyb4iz9bhhdq…
Bare goes inside your app: your users never install it, because it ships with what you build. You install it as a developer. `npm i -g bare` gives you the bare CLI and a REPL, so you can try the seal, run scripts and test modules on your machine before you embed it. The bare CLI is itself an app that embeds Bare: it's the embedder that hands bare-module a file-system protocol so scripts can read from disk.
Embed Bare. Pick the shape that fits what you're building:
- Native apps. Use Bare Kit on iOS, Android and React Native, or call the C API directly from your own native host. One core, many platforms explains how the same JavaScript core runs on each.
- Standalone executables. bare-build compiles your program and the runtime into one binary for desktop or terminal, and nothing needs to be installed on the user's machine. Seal from your entry point, before any code you don't fully trust runs. Bundle a Bare app walks through it.
- Workers. Bare.Thread and bare-worker start more threads inside the same process. The seal covers every thread, including ones started after it, so you can give a worker code you don't fully trust and no new native code gets in.
Seal it. Publish the handles your addons need with the embedder context API, load the addons you trust, then call Bare.Addon.seal() before any code you don't fully trust runs.
Ship it peer-to-peer with Pear. Deploy your app and update it over the air, with updates flowing directly between peers. Start from a template, or add Pear OTA to an app you already have.
Embedding Bare, sealing it, or shipping it with Pear? Join the Pear Development group on Keet and tell us what you're embedding Bare in.
