Issue 209: a bundle's own SDK copy registers into a registry the runtime never reads; design 38 WP4 note #316

Merged
mesh-admin merged 5 commits from issues/209-a-bundles-own-sdk-copy-registers-nowhere into main 2026-10-03 11:20:39 +00:00
Showing only changes of commit 55443b67e6 - Show all commits
@@ -201,7 +201,13 @@ broker per node. Two things the package did not say, settled in the module: the
run through `sudo` without a prompt where the runtime is not root, since the operator's account may run through `sudo` without a prompt where the runtime is not root, since the operator's account may
escalate as the operator would; and a bundle has no environment of its own, so the tool reads the escalate as the operator would; and a bundle has no environment of its own, so the tool reads the
filter from the path the manifest's `filtering` names rather than from a variable the container used filter from the path the manifest's `filtering` names rather than from a variable the container used
to carry. to carry, a test holding the two together. Three things a review of the change found: the module's
own bus credential and state directory went with the container, since nothing reads them once the
runtime speaks with the node's (the shell module of WP5 declares neither); the `iptables` package the
image used to carry is now declared on the host; and that the operator's account may escalate without
a prompt is a fact about the machine the mesh neither declares nor checks — true on all four today,
and when it is not, the tool names it by how it failed, which is the only check there is until a
record says where the fact belongs.
## WP5 — The shell, on a server first ## WP5 — The shell, on a server first