[raymondk]

Summary

First of three stacked PRs that bring icp deploy to the local MCP server through the icp CLI's own project library (icp-project, the code behind icp deploy). This one adds the crate and the library's Host for a bundle, the .tar.gz that icp project bundle writes. Nothing drives it yet; the pipeline is #231 in the stack and the MCP tools #232.

The bundle is untrusted input. A bundle is handed over by an agent, so the host takes it for exactly what a bundle is and no more:

• extract_bundle unpacks it into a scratch directory under a compressed-size limit (256 MiB) and a decompressed-stream limit (1 GiB), refusing symlinks and other non-file entries, more than 250,000 files and directories (counting the parents an entry's path implies), entry paths over 4096 bytes, and anything under .icp/ in any letter case, the id and artifact state a deploy seeds itself.
• The FileSystem the library reads the project through is the library's own files::Confined, the host filesystem held to the extraction directory: the root is opened once as a directory handle and every read is made beneath it, so the operating system refuses a path that leaves the root, by climbing, by being absolute elsewhere or by a symlink; on top of that, a path through a symlink is refused wherever it leads. The loader reads every path a manifest names through that one seam, so a manifest can name only what the archive brought with it. The project loader reads through a metered view of it, with a 256 MiB budget on what it retains.
• The loaded project is vetted by the library's untrusted rule (icp_project::untrusted::Vetted, what icp deploy --untrusted applies): each build step a pre-built module, each sync step a plugin, the file each names a regular file the confined filesystem will give, and what a plugin step hands its plugin a directory or regular file there too. A script step, a module or plugin fetched from a URL, or a path that is not such a file fails the load, before any phase. No recipe is fetched (untrusted::NoRecipes, the library's own): a recipe is read or fetched while the project loads, so a project naming one fails to load, naming the recipe.
• IcMainnet is the network seam: the reserved ic network as the loader supplies it (that name, the mainnet endpoint, the mainnet root key), nothing else. A manifest may declare a network of any other name that claims the mainnet root key over an endpoint of its own; refused.
• BundledWasm serves local wasm sources from the bundle, sha256 verified. NoScripts is the script runner the syncer is composed with; it spawns nothing, since the vetted loader admits no script step.
• check_bundle validates the whole bundle before a deploy would run: one pre-built step per canister naming a wasm in the archive that hashes to its recorded checksum (and, if gzip-compressed, expands to no more than 100 MiB, since the library gunzips it in memory unbounded), canister names that differ by more than letter case (the artifact store keys build output by name on disk), every sync plugin in the archive with the bytes its files: declare held to a sum, an environment on ic. A canister directory outside the root needs no check of its own any more: the confined loader does not find it, and the project does not load.

Relationship to icp-cli. The confinement used to live here, as an index-backed filesystem of this crate's own. The rule is one, split three ways upstream (dfinity/icp-cli#863, issue #865): the user's own project may run, fetch and link whatever it likes; icp project bundle writes an archive of regular files and directories with every step spelled out (#868); and a consumer of a bundle it does not trust loads it as untrusted (#873, on #868: files::Confined on cap-std, untrusted::NoRecipes and untrusted::Vetted). This PR pins the four icp-cli crates to icp-cli's main at the merge of #873 (8f98455, the squash of #873 on #868's merge). The Cargo.toml comment says so.

Why a new crate, and why unpublished. icp-project and its siblings are publish = false upstream, so they can only be git dependencies, and crates.io refuses any crate that carries one. imcp2-core and imcp2 publish there, so this is its own publish = false crate, composed into imcp2-local alone (in #232). The four icp-cli crates are pinned to one rev and must be bumped together. icp-sync-plugin brings wasmtime into the workspace, so builds are slower. The manifest carries the crate's full dependency list so the lockfile lands once; rmcp and base64 are used only from #232.

Most of host.rs exists because icp-project ships no host for a bundle. dfinity/icp-cli#863 asks for one upstream, with filesystem and browser backings, so this could later shrink to the MCP glue.

Related issues

• icp-project: loading a project does not confine the paths its manifest names icp-cli#865, #868 and #873: the confined filesystem and the untrusted rule this PR pins and composes.
• icp-project: a bundle host that treats the archive as untrusted, with filesystem and browser backings icp-cli#863
• Supersedes Add icp_deploy_bundle to the local MCP: deploy an icp project bundle via icp-project #216 together with the two PRs stacked on this one.

Changes

• crates/imcp2-deploy (new, publish = false, version 0.6.1 like the other crates): Cargo.toml, src/lib.rs (crate doc, pub mod host), src/host.rs.
• Workspace Cargo.toml adds the member; Cargo.lock gains the icp-cli crates and their tree (plus semver-compatible patch bumps of anyhow, toml, wasm-encoder/wasmparser/wast, and wasmtime 49.0.5 from the newer icp-cli pin).

Testing

• cargo build --locked --workspace --all-targets
• cargo test --locked --workspace --all-targets (the 23 in the new crate are new)
• cargo fmt --all -- --check / cargo clippy --locked --workspace --all-targets (clean)
• npm test --prefix monitoring/mcp-status (dashboard unchanged)

The tests are offline. The network seam: only the reserved ic is served, and it resolves to the pinned root key; a managed network, a fetched key, another name with the mainnet key, and the mainnet key over a loopback endpoint are refused. Extraction: no manifest, not an archive, oversize compressed, oversize decompressed, a symlink entry, an entry under .icp/ spelled plainly, as ./.icp/ and as .ICP/, too many files and directories (implied parents counted), an entry path past the length limit. A gzipped module is held to its limit. The bundle is served through the confined filesystem by any spelling inside the root, and absolute or climbing paths are refused as outside it; the filesystem's own spelling and symlink cases are tested upstream in icp-cli#873. The load refuses a script step, a remote module and a recipe, naming each; a module named through a symlink made after extraction, out of the root, within it or dangling, fails the load as not a regular file of the project, and a read through the link is refused naming it; a directory named as a module is refused; a root named through a link holds the project. A sync step's declared dirs: and files: are held to the bundle at the load and to a byte sum at the check. The loader's read budget is tested with two canisters naming one argument file.

Checklist

• I have read the Contributing guidelines.
• Docs (README / comments) updated for any user-visible change.
• No secrets, credentials, or internal-only information are included.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Unresolved critical findings permit archive-controlled state injection, host-file access, and requests to arbitrary network endpoints, while mismatched crate versions block releases.

4 open issues

• Restore the root package version to match workspace crates · New
• Require the reserved IC network for connected endpoints · New
• Reject canister directories outside the bundle root · New
• Normalize archive paths before checking extraction boundaries · New

What changed in this PR

Adds an unpublished imcp2-deploy crate implementing an icp-project host for untrusted project bundles. This establishes the foundation for the deployment pipeline and local MCP tools in the next two PRs.

Changes:

• Adds bounded archive extraction, an index-backed filesystem, and bundle validation.
• Implements network, wasm, and build adapters, with script execution refused and offline tests included.
• Registers the crate and locks the pinned icp-cli dependencies, including the Wasmtime runtime.

File	Description
crates/​imcp2-deploy/​src/​lib.rs	Documents the crate’s scope and exports the host module.
crates/​imcp2-deploy/​src/​host.rs	Implements bundle extraction, host adapters, validation, and tests.
crates/​imcp2-deploy/​Cargo.toml	Defines the unpublished crate and pins icp-cli dependencies.
Cargo.toml	Adds the workspace member and changes root version declarations.
Cargo.lock	Records the new dependency tree and package version updates.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Unresolved critical flaws allow case-insensitive aliases to introduce unintended deployment targets or substitute Wasm artifacts, while unbounded decompression and quadratic index scans expose the server to memory and CPU exhaustion.

4 open issues

• Avoid quadratic index scans for recursive glob lookups · New
• Reject canister names that alias in the artifact store · New
• Bound gzip decompression during bundle preflight · New
• Reject case-insensitive aliases of the reserved extraction directory · New

4 resolved since last review

• Normalize archive paths before checking extraction boundaries
• Reject canister directories outside the bundle root
• Require the reserved IC network for connected endpoints
• Restore the root package version to match workspace crates

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Critical resource-budget gaps in archive extraction, plugin execution, and project loading allow crafted bundles to exhaust server memory, disk space, or inodes.

No open issues 🎉

3 previously missed issues

In code that hasn't changed since last review

Repeated file-backed arguments bypass the project-loading memory limit

crates/​imcp2-deploy/​src/​host.rs:361

Project loading can exhaust memory before check_bundle runs: the pinned loader reads each file-backed argument into a separate owned value retained by its canister. Fifty canisters referencing the same 100 MiB binary argument retain roughly 5 GiB despite staying within the extraction limits. Enforce a cumulative project-loading read budget, counting repeated reads, before allocating and returning these buffers to ProjectLoadImpl.

Plugin execution lacks a store memory resource limiter

crates/​imcp2-deploy/​src/​host.rs:744

The pinned Wasmtime runner executes bundle-supplied plugins in the server process with stack and epoch limits but no store resource limiter. A small component can allocate and touch multiple GiB of linear memory, potentially exhausting server memory before the timeout; archive limits do not constrain these allocations. Use a runner with aggregate memory, table, and instance budgets, or run plugins in an OS-resource-limited subprocess.

Implicit archive directories bypass the filesystem-object limit

crates/​imcp2-deploy/​src/​host.rs:827

The entry cap counts archive records, but unpack_in also creates every missing parent directory. A bundle of empty files beneath distinct, deep directory chains can stay within both byte limits and the entry cap while creating millions of directories, exhausting disk space or inodes. Count distinct implicit parent directories against a filesystem-object budget before unpacking each entry.

4 resolved since last review

• Reject case-insensitive aliases of the reserved extraction directory
• Bound gzip decompression during bundle preflight
• Reject canister names that alias in the artifact store
• Avoid quadratic index scans for recursive glob lookups

_{Review effort: Balanced}

[raymondk]

The three "previously missed" findings in the last review, addressed in ec3c3c3:

• Repeated file-backed arguments bypass the project-loading memory limit. The project loader now reads through a metered view of the bundle (Metered in host.rs), charged by file size before each read, with MAX_PROJECT_BYTES (256 MiB) for everything it loads: manifests, argument files and variable files, counted once per canister that names them. The phases keep reading the bundle itself, so a module read several times over a deploy is not charged. Tested at loading_the_project_is_held_to_its_read_budget (two canisters naming one file: the second read is what trips the budget).
• Implicit archive directories bypass the filesystem-object limit. Extraction now counts files and directories alike against MAX_BUNDLE_ENTRIES, charging each directory an entry's path implies once (read off the index and the directory entries written so far). Since that walk costs a lookup per component, an entry's path is first held to MAX_ENTRY_PATH_BYTES (4096, Linux's PATH_MAX). Tested at the_directories_an_archive_implies_count_against_its_cap and an_entry_path_past_the_length_limit_is_refused.
• Plugin execution lacks a store memory resource limiter. Not bounded here, and host_for's docs now say so. The runner is icp_sync_plugin::Wasmtime, which builds its own Engine and Store inside a private function; nothing on this side of its Run trait can attach a StoreLimits, and the real plugins (e.g. the certified-assets plugin) declare no memory maximum, so a static check on the component would refuse them. The fix is a store limiter in icp-sync-plugin's runner upstream, after which this crate bumps the pinned rev.

#231 and #232 are rebased on top locally and get pushed next.

[Copilot]

🟡 Changes recommended

Unbounded plugin input loading and repeated module decompression allow untrusted bundles to exhaust host memory or monopolize the server.

6 open issues

• Bound repeated module validation work · New
• Bound aggregate plugin input bytes before sync · New
• Limit scratch cleanup to indexed descendants · New
• Validate declared plugin input paths during preflight · New
• Avoid double-counting implied directory parents · New
• Track explicit and scratch directories in filesystem state · New

_{Review effort: Balanced}

[aterga]

Can we avoid adding some of these 3rd party crates?

For the ones that we cannot replicate, let's have an explicit analysis of the pinned version, since this repo is particularly sensitive to supply chain vulnerabilities.

[raymondk]

Our own additions are two crates, camino and tar (flate2, tempfile and async-trait were already in the tree). The other ~125 new packages come through the four icp-cli crates: ~60 are wasmtime/cranelift via icp-sync-plugin (the CLI runs sync steps, asset upload included, as wasm plugins), ~10 are cap-std via icp-project's confined filesystem, ~10 are ic-cdk/ledger types via icp-canister-interfaces. Those can't be dropped without reimplementing the CLI's sync runtime. For the rest, I can add a cargo-vet/cargo-deny policy in CI or a per-version review of the pinned set — say which.

[Copilot]

🟡 Changes recommended

Untrusted plugins can exhaust MCP server memory because the runner lacks hard guest/store memory limits, and existing archive, module-expansion, and file budgets do not constrain guest allocations.

1 open issue

• Enforce guest memory limits for untrusted plugins · New

6 resolved since last review

• Bound aggregate plugin input bytes before sync
• Bound repeated module validation work
• Track explicit and scratch directories in filesystem state
• Avoid double-counting implied directory parents
• Validate declared plugin input paths during preflight
• Limit scratch cleanup to indexed descendants

_{Review effort: Balanced}