Sandboxed builds

When nem installs a package, it runs the build, install, and test steps from the package’s pkg.yaml. Some of those steps run third-party commands — especially for packages built from source — so nem runs them inside a sandbox by default. The artifact is fetched and SHA-256-verified first; the steps then run isolated.

What the sandbox restricts

Both build and test run steps execute inside the sandbox.

• No network. Network access is denied inside the sandbox, so a build or test step can’t reach out and pull in unverified code. Everything it needs was already downloaded and checksummed.
• Read-only filesystem. The host filesystem is mounted read-only. Only a per-phase writable directory is exempt: the staging area for build steps, and an ephemeral scratch directory (also TMPDIR and the default cwd) for test steps.

Platform requirements

The sandbox uses each platform’s native isolation, and is required — if the tool below is missing, the install fails rather than silently running unsandboxed.

• macOS — /usr/bin/sandbox-exec, built into the OS.
• Linux — bubblewrap (bwrap), which you install through your system package manager.

If nem doctor reports the Sandbox check failing, install the tool above. See Troubleshooting.

Disabling the sandbox

Disable it with NEM_SANDBOX=0, or sandbox: false in ~/.nem/config.yaml:

NEM_SANDBOX=0 nem use <package>

Build and test steps then run with unrestricted network and filesystem access. Only do this when sandboxing is absolutely not an option, and you trust the package’s steps. See Configuration.

For the build, install, and test steps a manifest can declare, see the pkg.yaml schema.