Repository navigation
feat(minimald): put the proxy's root certificate in a grant box's trust store - #2495
norrietaylor merged 9 commits into
Conversation
BEP-011: the box record carries the root certificate the create requ 8000 est handed it, so every host launch reads it, after a daemon restart included. A launch of a box with a credentialed upstream and steering other than off writes the root into the box's own copy of the CA bundle and links it in /etc/ssl/certs under its OpenSSL subject hash. Each file is a new file, never a write through the package store's hardlink. SSL_CERT_FILE, REQUESTS_CA_BUNDLE and NODE_EXTRA_CA_CERTS sit below the composition, so a spec value stays. One debug line per box says whether the root went in.
BEP-011: ActivationPlan::warn_spec_trust_env adds a warning that names each of SSL_CERT_FILE, REQUESTS_CA_BUNDLE and NODE_EXTRA_CA_CERTS the spec's environment sets, for a box that gets the proxy's root.
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Adds three session-e2e cases: the root in both trust-store forms, no root in a box with no grant, and the trust variables.
A target dir can hold a min and a minimald from two builds, one from a dirty tree. The CLI then refuses the daemon at the first activate. The script now rebuilds such a pair, and reruns the version build script so both halves get one version.
ba36c5d to
0753734
Compare
There was a problem hiding this comment.
Babysitter review of T16 against its plan block, at 0753734d.
Layer carry. Record.root_certificate sits beside sealed_deliveries with the same serde shape, the record build in box_manager.rs copies it from the create request, and record_carries_the_root_certificate_to_the_launch pins the copy, the JSON round trip, the off-steering refusal and the no-grant case. box_runtime/launcher.rs moves the root into the env build and the trust variables onto the baseline layer. Present as the amended plan asks.
Layer trust. env.rs writes the root into the box's own trust store in both forms: the root alone, the box's own bundle copy with the root appended, and the <subject hash>.N link in the hashed directory. Each file is written as a new file after the old name is removed, so a hardlink to the package store keeps its target, and a link resolves inside the rootfs. Three unit tests pin the copy-never-the-store rule, the in-rootfs link rule and the refusal of a non-certificate. box_runtime.rs sets SSL_CERT_FILE, REQUESTS_CA_BUNDLE and NODE_EXTRA_CA_CERTS only when the root is injected, below the composition, so a spec's own value wins; two tests pin that. The root is injected only for a box with a credentialed upstream whose steering is not off, which matches BEP-010. scripts/session-e2e.sh adds the three cases the plan names, wired into the full run, the dispatcher and the usage text; they record NOT RUN on every CI lane today, because they need a running proxy, which T18 #2275 brings.
Layer spec. BepWarning::TrustEnvSetBySpec and ActivationPlan::warn_spec_trust_env exist with the plan's exact text, pinned by spec_trust_env_shadows_platform_with_warning. Nothing calls them yet: the agent's notes say the call belongs in crates/minimal/src/cmd/boxes/create.rs, outside the layers, so min does not print the warning the plan's diagnostics line requires. The babysitter asks for that one-line call in a /revise and accepts the file under the layer-exception rule.
Out of the layers. Eight files gain root_certificate: None in record struct literals, which the plan's carry layer anticipates; crates/minimald/src/box_actor/launcher.rs gains two lines that hand the record's root to the launcher. Accepted under the epic's layer-exception rule; the body's "Layer exception" section records them, and the babysitter undrafts the PR.
For the reviewers. env.rs carries its own SHA-1, base64 decoder and X.509 subject canonicaliser (about 400 lines with tests) to compute OpenSSL's subject hash for the link name, because minimald holds no X.509 or digest crate. The hash is checked against two openssl-issued fixtures. A sha1 crate would drop the digest; the canonicaliser would stay. Whether that trade is right is the reviewers' call.
Commits. Two commit bodies had lines over 100 columns, which commitlint refuses. Under the epic's commitlint rule the babysitter reworded them in place (4ab8fa85 to fa732d3c, ba36c5d7 to 0753734d), content and author unchanged, and force-pushed with lease. Every commit now passes commitlint.
No blocking findings of my own.
Generated by Claude Code
|
/revise Wire the BEP-011 warning the plan's diagnostics line requires. Generated by Claude Code |
|
Approved: no findings at Nothing to do. Verdict APPROVE, posted as a comment: the App cannot review its own pull request; the check and the label carry it. Clobber: none seen. |
There was a problem hiding this comment.
arch-review: CONDITIONS · 3 conditions · the full ruling
The trust-store write is in the right place and follows the iff of Gatehouse §6.10. Three items remain. First, the shadow warning that §6.10 line 821 requires is never printed, because warn_spec_trust_env has no caller. Make the change in C1. Second, the no-grant e2e leg exited 1 on Linux. Make it pass, as C2 says. Third, a box with no CA bundle in its packages gets trust variables that name a root-only file, which breaks the additive rule. Make the change in C3.
Ruled at 0753734 against gominimal/arch@109541a48c31 by claude-opus-5-5.
The activation passes the names of the variables the project's minimal.toml sets to warn_spec_trust_env, so a grant box that sets SSL_CERT_FILE, REQUESTS_CA_BUNDLE or NODE_EXTRA_CA_CERTS itself prints the BEP-011 warning on stderr with the other activation warnings.
There was a problem hiding this comment.
Babysitter review of T16 at 947ab1f9 (round 1).
The round changes crates/minimal/src/cmd/boxes/create.rs alone, the one-line layer exception the /revise named plus its plumbing: project_bep_and_grants now also returns the names of the variables the box spec's own environment sets, refuse_unhonourable_grants calls warn_spec_trust_env with them before it prints the plan's warnings, and the function returns the warnings so a test can read them. spec_trust_env_warns_at_activation pins the exact text for a spec that sets SSL_CERT_FILE with a GitHub grant, and no warning without it. That is the arch review's C1 and both of the code reviewer's MEDIUM findings. The existing callers are updated and nothing else moves.
Open from the ruling at 0753734d: C2, the no-grant e2e leg on Linux, and C3, the root-only bundle when the packages ship none. Both go in the next round.
No blocking findings of my own.
Generated by Claude Code
There was a problem hiding this comment.
minimal-review — approval withheld
Verdict COMMENT — APPROVE withheld: 5 unresolved threads — minimal-foundry[bot] crates/boxes/src/core/bep.rs:722, minimal-foundry[bot] crates/boxes/src/core/bep.rs:723, minimal-arch[bot] crates/boxes/src/core/bep.rs:707, minimal-arch[bot] scripts/session-e2e.sh:11834, minimal-arch[bot] crates/minimald/src/env.rs:922. No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
There was a problem hiding this comment.
arch-review: CONDITIONS · 2 conditions · the full ruling
The trust-store code conforms to Gatehouse §6.10 lines 819 and 821. The node writes the root in both forms, additive, and only for a grant box with steering on. The compare wires the shadowing warning at activation, as line 821 requires. The proof is open. The no-grant leg exited 1 on Linux, and C1 fixes that. The grant legs are NOT RUN, and C2 runs them on the macOS lane.
Ruled at 947ab1f against gominimal/arch@109541a48c31 by claude-opus-5-5.
|
Round 1 of 10 on a /revise note, pushed as
Verify Outside the task's
Converted to a draft: something above needs a person before review. A grant box has the root in both trust-store forms, and a box with no grant has none. This round adds one more fact: Notes from the agent: Revise round 1: I did what the /revise note asked, in crates/minimal/src/cmd/boxes/create.rs only. That file is outside the layers, and the note accepts it as a layer exception. project_bep_and_grants also returns the names from [session] vars and vars_lenient. refuse_unhonourable_grants takes those names, calls ActivationPlan::warn_spec_trust_env, prints each warning with the same |
|
/revise Act on the arch review's C3 at Generated by Claude Code |
When a grant box's packages ship no CA bundle, the root no longer becomes a bundle of its own. The box keeps the root file and its hashed-directory link, and only NODE_EXTRA_CA_CERTS names the root. SSL_CERT_FILE and REQUESTS_CA_BUNDLE are set only when the box has a bundle, so a tool that reads them keeps its public roots. The env build sets the trust variables now, below the composed ones, because it is where the bundle is known before the rootfs is built.
There was a problem hiding this comment.
arch-review: PASS_WITH_CONDITIONS · 1 condition · the full ruling
The compare stops writing a root-only bundle when the packages ship no CA bundle. Gatehouse §6.10 line 821 makes the anchor additive and never anchor-only, so this is the correct behaviour. The box keeps the root file and the hashed link. Only NODE_EXTRA_CA_CERTS names the root, because no merged bundle exists. BEP-011 conforms. C1 is open: the three grant e2e legs must pass under #2275 before BEP-011 is proved in a real box.
Ruled at 848cf43 against gominimal/arch@109541a48c31 by claude-opus-5-5.
There was a problem hiding this comment.
Babysitter review of T16 at 848cf437 (round 2).
The round answers the arch review's C3. install_root_certificate now writes the box's bundle only when the packages ship one, and reports whether it did; a box with no bundle keeps the root file and its hashed-directory link and gets NODE_EXTRA_CA_CERTS alone, so a tool that reads the bundle variables keeps its public roots. The trust variables moved from the launcher's baseline layer into the env build, which knows the package layers and so whether a bundle exists, and they are added below every variable the box already holds, so a spec's own value still wins; trust_env_keeps_a_spec_value and trust_env_points_at_bundle_and_root are updated for both shapes, and the no-bundle rootfs test now asserts no bundle is written. The arch review ruled PASS_WITH_CONDITIONS at this head; its one condition is the three grant legs passing under T18 #2275, which is the residual already filed there.
Open: the code reviewer's security finding that the daemon writes the whole PEM string into the trust store and the bundle while it checks only the first certificate block, so a record PEM with extra blocks would add extra anchors. The client refuses such a PEM, but the daemon does not repeat the check. The next round makes the daemon write the first block alone or refuse more than one.
No blocking findings of my own.
Generated by Claude Code
|
Round 2 of 10 on a /revise note, pushed as
Verify Outside the task's
Converted to a draft: something above needs a person before review. Review threads the coder judged:
A grant box whose packages ship a CA bundle has the root in both trust-store forms. It also has SSL_CERT_FILE and REQUESTS_CA_BUNDLE at its own bundle copy and NODE_EXTRA_CA_CERTS at the root. A grant box whose packages ship no bundle keeps the root file and the hashed-directory link. It gets no bundle and only NODE_EXTRA_CA_CERTS, so a tool that reads the bundle variables keeps its public roots. A box with no grant gets none of these. The unit tests trust_env_points_at_bundle_and_root and root_certificate_follows_links_inside_the_rootfs pin both cases. Notes from the agent: C3 (revise note). install_root_certificate now returns RootInstall { link, bundle }. When the packages ship no bundle, it writes no bundle. launch_trust_env(root_injected, bundle) sets the two bundle variables only when bundle is true. The sandbox fixes a box's variables in its config before the rootfs exists, and the sandbox crate has no way to unset a variable later. For that reason Env::build now sets the trust variables, not the launcher. Before the sandbox build, it checks the package layers for the bundle (layers_ship_ca_bundle), and it adds the variables with or_insert below the composed ones (layer_trust_env), so a box spec value still wins. The launcher line that put them on the baseline layer is removed, and trust_env_keeps_a_spec_value now exercises layer_trust_env. After the install, the debug line says when the packages ship no bundle, and it records bundle_variables (the result of the layer check). The two checks can disagree only when a bundle link crosses from one package layer into another. That rare case leaves the bundle variables unset. scripts/session-e2e.sh is not changed: its trust-env case uses a box with a bundle, and that case is NOT RUN on Linux. The e2e no-grant case fails on this machine because boxes cannot start here (mount remount EPERM). It is not a result of this change. |
|
/revise Act on the review's security finding at Generated by Claude Code |
The daemon checked the first certificate block of the record PEM but wrote the whole string. A PEM with more blocks added trust anchors. Refuse such a PEM and write the one block's own text.
There was a problem hiding this comment.
arch-review: PASS_WITH_CONDITIONS · 1 condition · the full ruling
The compare conforms to Gatehouse §6.10. Only the one root certificate block now reaches the box trust store. A PEM with no block or with two blocks fails the launch, and that is fail closed. One anchor per box matches line 839, because an un-enrolled root replacement re-creates the box. The three grant e2e legs are still NOT RUN. C1 keeps them open on #2275 until they pass on the macOS lane.
Ruled at 6f065b6 against gominimal/arch@109541a48c31 by claude-opus-5-5.
There was a problem hiding this comment.
minimal-review — approval withheld
Verdict COMMENT — APPROVE withheld: 2 unresolved threads — minimal-foundry[bot] crates/minimald/src/env.rs, minimal-arch[bot] scripts/session-e2e.sh:11862. No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
There was a problem hiding this comment.
Babysitter review of T16 at 6f065b65 (round 3).
The round changes crates/minimald/src/env.rs alone: install_root_certificate now takes the one certificate block out of the record's PEM, refuses a PEM with no block or more than one with the same InvalidData error as a non-certificate, and writes that block alone into the root file and the bundle, so text around it or a second block never reaches the box's trust store. Two tests pin the refusal of a two-block PEM and the dropping of surrounding text. That is the code reviewer's security finding, and the arch review's ruling at this head records the behaviour as fail-closed and conforming. Its one condition is the three grant legs under T18 #2275, the residual already filed there.
No blocking findings of my own. Ready for the merge gate once CI and the code reviewer finish at this head.
Generated by Claude Code
There was a problem hiding this comment.
minimal-review — approved
Verdict APPROVE — every review thread is resolved; @norrietaylor closed the last one. The review of 6f065b6514fe withheld this approval on the threads open then. Posted as a comment: the App cannot approve its own pull request; the check and the label carry it.
|
Round 3 of 10 on a /revise note, pushed as
Verify Outside the task's
Converted to a draft: something above needs a person before review. Review threads the coder judged:
A grant box has the proxy's root in both trust-store forms, and a box with no grant has none. The daemon now refuses a root PEM with more than one certificate block, and it writes only the one block's own text, so no other trust anchor reaches the box. Notes from the agent: Revise round 3: install_root_certificate now takes the one certificate block through a new certificate_block helper. A PEM with no block or with more than one block gets the same InvalidData error as before. Only the block text, from BEGIN through END, goes into the root file and the bundle. New tests: root_certificate_with_two_blocks_is_refused (the pin the directive asked for) and root_certificate_text_outside_the_block_is_dropped. I did not run the three session-e2e.sh lines or the boxes test in this round. This round did not change their code paths, and the e2e lines need a KVM host. cargo clippy -p minimald --all-targets shows only warnings in files this round did not touch (box_runtime/handle.rs, net/switch.rs, minimald-rpc/src/trace.rs). |
…terception-root-in-the-box-s-trust-sto
|
/revise CI's Linux KVM lane fails at Generated by Claude Code |
|
That Nothing to type again: the command gets a rocket when its round starts, or a refusal that names the reason. No round was counted for it yet. |
The plain box in bep_root_ca_absent_from_box_without_credentialed_upstream passed the GitHub --allow-dns-hosts flags. On the KVM lane a host_ip box refuses hostname rules at the start, so its activate failed. Only the grant box declares those hosts now.
There was a problem hiding this comment.
arch-review: PASS_WITH_CONDITIONS · 1 condition · the full ruling
The new commit removes the GitHub egress flags from the no-grant box in the BEP-011 e2e. Section 6.10 line 819 keys injection on credentialed upstreams, not on egress hosts. So the absence proof stays as hard as before. The code still conforms to the Trust-store injection paragraph (line 821). The three grant legs still record NOT RUN. C1 keeps them open on #2275 until the macOS lane runs them with a live proxy.
Ruled at d5be668 against gominimal/arch@109541a48c31 by claude-opus-5-5.
There was a problem hiding this comment.
Babysitter review of T16 at d5be6688 (round 4).
The round changes scripts/session-e2e.sh alone: bep_trust_box_files passes the four GitHub --allow-dns-hosts rules only for the grant box, and starts the no-grant box with no egress rule, which is what the KVM lane's default network mode refused at 6f065b65. The rest of the compare is main merged in: the listing host-slot change from #2231, no PR content. The code reviewer approved at this head with no findings, and no thread is open.
No blocking findings of my own. The KVM and macOS lanes decide the proof; ready for the merge gate when they are green.
Generated by Claude Code
|
Round 4 of 10 on a failed check suite, pushed as
Verify Outside the task's
Converted to a draft: something above needs a person before review. A grant box has the root in both trust-store forms, and a box with no grant has none. This round, the no-grant case starts its box on the KVM lane again, so that lane can show that a box with no grant has no root. Notes from the agent: Round 4 cause: the public check-run annotations for test-kvm name the failure as "'min session activate' of the plain box for bep_root_ca_absent_from_box_without_credentialed_upstream failed". That case runs on every lane with no gate. Its plain box passed the four GitHub --allow-dns-hosts flags without --network own_ip. On a VM host, a host_ip box with hostname rules is refused at the start (minimald net/classifier.rs unenforceable_declaration_words). Now only the grant box passes those flags. The empty array expands with the ${a[@]+...} form so bash 3.2 on macOS with set -u accepts it. The stderr of the CI activate was not readable (job logs need admin rights), so this cause is inferred from the annotation and the code. On this box the activate now succeeds, but the exec step fails. The baseline ./scripts/session-e2e.sh session_exec fails here with the same 'sandbox supervisor ... has no child process' error, so this box cannot run box execs. The KVM lane is the record for the e2e cases. The two grant cases report NOT RUN here because the Box Egress Proxy is not running on this lane. |
|
Round 5 of 10 on a /revise note: the coder changed nothing. noop: the branch head d5be668 already does what the note asks. bep_trust_box_files passes the four --allow-dns-hosts flags only when $2 is grant. It activates the plain box with no egress flags, and the grant box flags are unchanged. No new commit is needed. Confirmation on this box is partial. The plain box activate now succeeds, and the KVM lane failed at that step. The next step, 'min session exec', fails here. The baseline session_exec e2e case fails at the same step, so this sandbox cannot run box execs. This box has no /dev/kvm, so it cannot reproduce the KVM lane. The test-kvm lane must re-run at d5be668 to confirm the plain leg exits 0. |
There was a problem hiding this comment.
Approved by the babysitter at d5be6688 after the merge gate passed on every point: own reviews at every head, arch-review PASS_WITH_CONDITIONS at d5be6688 whose one condition is the residual filed on T18 #2275, the code reviewer's approval, every review thread resolved, every CI lane green including KVM and macOS, and the squash subject lint-clean. Layer exceptions and CI evidence are recorded in the body. Enqueued for a squash merge.
Generated by Claude Code
T16 — Put the interception root in the box's trust store
slice: S0
kind: task
covers: BEP-011
size: L
est: 330 code, 420 tests
executor: agent
difficulty: needs care
model: standard
diagnostics: a box spec that sets one of the three trust variables itself keeps its value and activation prints "This box sets itself, so tools that read it will not trust the proxy's certificate." on stderr, pinned by spec_trust_env_shadows_platform_with_warning
observability: one debug log line per box naming whether the root was injected
layers:
- carry:
- crates/boxes/src/lib.rs:
Record.root_certificate, the proxy's root certificate PEM besidesealed_deliveries, so every host launch of the box reads it, after a daemon restart included (stale layers found by the coder on 2026-10-22; the record fixtures are struct-literal additions)- crates/minimald/src/box_manager.rs: the record build copies
config.root_certificatefrom the create request- crates/minimald/src/box_manager/tests.rs: the record test
- crates/minimald/src/box_runtime/launcher.rs: the launch hands the record's root certificate to
EnvArgs, soEnv::buildwrites the box's bundle copy and hashed directorytest: cargo nextest run -p minimald record_carries_the_root_certificate_to_the_launch
- trust:
- crates/minimald/src/env.rs: the root in the box's own bundle copy and hashed directory, per BEP-011, never the package store's copy
- crates/minimald/src/box_runtime.rs: the trust variables of BEP-011
- crates/minimald/src/box_runtime/tests.rs: the trust-variable tests
- scripts/session-e2e.sh: adds three cases
test: ./scripts/session-e2e.sh bep_root_ca_present_in_box_trust_store
test: ./scripts/session-e2e.sh bep_root_ca_absent_from_box_without_credentialed_upstream
test: ./scripts/session-e2e.sh bep_trust_env_points_at_bundle_and_root
- spec:
- crates/boxes/src/core/bep.rs: the warning for a spec that sets a trust variable
test: cargo nextest run -p boxes spec_trust_env_shadows_platform_with_warning
produces: none
consumes:
- crates/minimald-rpc/src/lib.rs
- crates/boxes/src/core/bep.rs
proof: A grant box has the root in both trust-store forms, and a box with no grant has none.
depends on:
- blocked by #2264
- blocked by #2273
- blocked by #2488
Layer exception
Nine files outside T16's
layers:carry changes the task cannot avoid, accepted under the epic's layer-exception rule of 2026-10-19; the babysitter undrafted the PR on them.crates/boxes/src/store.rs,crates/minimal-client/src/box_registration.rs,crates/minimal/src/cmd/boxes/vm_host.rs,crates/minimal/src/dash/render.rs,crates/minimal/src/dash/rpc.rs,crates/minimal/tests/dash_snapshots.rs,crates/minimald/src/exec/tests.rs,crates/minimald/src/store.rs: oneroot_certificate: Noneline each in aRecordstruct literal, the fixtures the plan'scarrylayer anticipates.crates/minimald/src/box_actor/launcher.rs: two lines that hand the record's root to the launcher, where the launcher literal is built.crates/minimal/src/cmd/boxes/create.rs(round 1): the call towarn_spec_trust_envwith the spec's own variable names, where the activation plan is projected, sominprints the BEP-011 warning the plan's diagnostics line requires; the arch review's C1 asked for it there.Evidence from CI
The Linux native lane at
0753734d(run 39877721856, jobnative-daemon-e2e120167546161) ran the no-grant leg ofbep_root_ca_absent_from_box_without_credentialed_upstreamon a target with no proxy and it passed:The exit 1 in the Tests table below is the coder's sandbox, where
min session execin the plain box failed before the check ran. Recorded by the babysitter for the arch review's C2.Residuals
bep_root_ca_present_in_box_trust_store, the grant half ofbep_root_ca_absent_from_box_without_credentialed_upstream,bep_trust_env_points_at_bundle_and_root) record NOT RUN until a live proxy runs beside gvproxy on the macOS lane. Filed on T18 #2275, whosee2elayer now names them (arch C2 at947ab1f9).Proof
A box created with a GitHub grant now launches with the proxy's root certificate at /etc/ssl/certs/minimal-box-egress-proxy-root.pem, appended to its own copy of /etc/ssl/certs/ca-certificates.crt, and linked as /etc/ssl/certs/.N. Its SSL_CERT_FILE and REQUESTS_CA_BUNDLE name the bundle, and NODE_EXTRA_CA_CERTS names the root. A box with no grant gets no root file, no link and no trust variables. The unit tests show this. The e2e cases that show it inside a real box did not run on this Linux box.
Notes from the agent: Out-of-layer files: crates/minimald/src/box_actor/launcher.rs sets SandboxLauncher.root_certificate from the record (the launcher literal is built there). Adding Record.root_certificate needed
root_certificate: Nonein struct-literal fixtures in crates/boxes/src/store.rs, crates/minimal-client/src/box_registration.rs, crates/minimal/src/cmd/boxes/vm_host.rs, crates/minimal/src/dash/rpc.rs, crates/minimal/src/dash/render.rs, crates/minimal/tests/dash_snapshots.rs, crates/minimald/src/store.rs and crates/minimald/src/exec/tests.rs. The task's layer note for lib.rs anticipates these fixtures.Not done: BepWarning::TrustEnvSetBySpec and ActivationPlan::warn_spec_trust_env exist and are tested in crates/boxes/src/core/bep.rs, but no caller passes the spec's variable names yet. The call belongs in crates/minimal/src/cmd/boxes/create.rs (where the activation plan is projected), which is outside the layers. So
mindoes not print the warning yet. The warning fires only when the plan injects the root (inject_ca).The spec value wins over the platform trust variables because they go on the launcher's baseline env layer, below the composition (tested by trust_env_keeps_a_spec_value).
The root is injected only when the record carries a root, the policy has a credentialed upstream, and steering is not Off. env.rs logs one debug line per box saying whether it was injected.
env.rs writes the bundle at /etc/ssl/certs/ca-certificates.crt. …[truncated]
Tests
cargo nextest run -p minimald record_carries_the_root_certificate_to_the_launch./scripts/session-e2e.sh bep_root_ca_present_in_box_trust_store./scripts/session-e2e.sh bep_root_ca_absent_from_box_without_credentialed_upstream./scripts/session-e2e.sh bep_trust_env_points_at_bundle_and_rootcargo nextest run -p boxes spec_trust_env_shadows_platform_with_warningVerify
min task run agent-verifyexited 101 under rustc 1.98.1, which the repository does not pin (1.97.0 in rust-toolchain.toml); the PR is not a draft on that alone — CI, which honours the pin, is the gate.Out of scope
These files are outside the task's
layers:, so this PR is a draft:crates/boxes/src/store.rscrates/minimal-client/src/box_registration.rscrates/minimal/src/cmd/boxes/vm_host.rscrates/minimal/src/dash/render.rscrates/minimal/src/dash/rpc.rscrates/minimal/tests/dash_snapshots.rscrates/minimald/src/box_actor/launcher.rscrates/minimald/src/exec/tests.rscrates/minimald/src/store.rsCloses #2274
Generated by Claude Code