Problem
v8_enable_sandbox requires V8_FROM_SOURCE=1, but v8 v152.1.0 from crates.io cannot complete that build because required source inputs are absent from the package.
Why this matters
We hit this while evaluating celld as a stateful V8 execution substrate for customer-authored workflows and agents. Celld does not currently claim hostile multi-tenant isolation, so enabling V8's software sandbox is one concrete defense-in-depth step toward safely running untrusted code.
This is not a theoretical consumer. After working around the packaging gap, we built celld with v8_enable_sandbox = true, adapted its one incompatible ArrayBuffer backing-store call, and successfully ran both a stateless Worker and a SQLite Durable Object.
The missing inputs mean a normal crates.io consumer cannot reproduce that hardening path. It must instead assemble and patch a full rusty_v8 source checkout outside Cargo. That makes sandbox-enabled builds difficult to pin, automate in CI, and keep current with security releases.
We are not specifically asking for a prebuilt sandbox archive. A documented and CI-covered full-source workflow would solve the problem too.
Reproduction
v8 = { version = "152.1", features = ["v8_enable_sandbox"] }V8_FROM_SOURCE=1 cargo build
Tested on macOS arm64 with Rust 1.94.1 and Ninja 1.13.
Observed
The build stops on missing inputs, in order:
third_party/disarm/src/parse.pythird_party/icu/common/icudtl.datthird_party/rust/chromium_crates_io/vendor/...
A full v152.1.0 checkout with submodules plus disarm at V8's DEPS-pinned commit builds successfully. A real celld consumer then compiled and ran with v8_enable_sandbox = true.
Expected
There should be one documented, CI-covered way for a crates.io consumer to build features that require V8_FROM_SOURCE=1: either publish the required inputs or direct Cargo consumers to a reproducible full-source path.
Related: #1999 covers ICU data staging, but not the other missing published-package inputs.
Problem
v8_enable_sandboxrequiresV8_FROM_SOURCE=1, butv8 v152.1.0from crates.io cannot complete that build because required source inputs are absent from the package.Why this matters
We hit this while evaluating celld as a stateful V8 execution substrate for customer-authored workflows and agents. Celld does not currently claim hostile multi-tenant isolation, so enabling V8's software sandbox is one concrete defense-in-depth step toward safely running untrusted code.
This is not a theoretical consumer. After working around the packaging gap, we built celld with
v8_enable_sandbox = true, adapted its one incompatible ArrayBuffer backing-store call, and successfully ran both a stateless Worker and a SQLite Durable Object.The missing inputs mean a normal crates.io consumer cannot reproduce that hardening path. It must instead assemble and patch a full rusty_v8 source checkout outside Cargo. That makes sandbox-enabled builds difficult to pin, automate in CI, and keep current with security releases.
We are not specifically asking for a prebuilt sandbox archive. A documented and CI-covered full-source workflow would solve the problem too.
Reproduction
Tested on macOS arm64 with Rust 1.94.1 and Ninja 1.13.
Observed
The build stops on missing inputs, in order:
third_party/disarm/src/parse.pythird_party/icu/common/icudtl.datthird_party/rust/chromium_crates_io/vendor/...A full
v152.1.0checkout with submodules plusdisarmat V8's DEPS-pinned commit builds successfully. A real celld consumer then compiled and ran withv8_enable_sandbox = true.Expected
There should be one documented, CI-covered way for a crates.io consumer to build features that require
V8_FROM_SOURCE=1: either publish the required inputs or direct Cargo consumers to a reproducible full-source path.Related: #1999 covers ICU data staging, but not the other missing published-package inputs.