Repository navigation
chore(cve): runtime CVE hygiene — 32/34 closed (94%), wasmtime 17→36, 207-line Cargo.lock reduction - #1
Closed
SashaMIT wants to merge 15 commits into
Closed
chore(cve): runtime CVE hygiene — 32/34 closed (94%), wasmtime 17→36, 207-line Cargo.lock reduction#1SashaMIT wants to merge 15 commits into
SashaMIT wants to merge 15 commits into
Conversation
Pure-setup commit. NO Cargo.toml / Cargo.lock changes. - Brings docs/vz-backend/RUNTIME_CVE_HANDOFF.md across from sash/local-test. The doc was authored during Phase 10 Day 1 on the substrate branch as a formal handoff packet for the broader runtime team; it lives on main-derived `chore/runtime-cve-hygiene` now because that is where the remediation work actually happens. - Adds docs/vz-backend/cve-hygiene/BASELINE_2026-05-26.md — a live capture of `cargo audit` against `main@5b90ea8`: - 34 vulnerabilities (identical to Phase 10 Day 1 baseline; zero closed by upstream releases in the interim). - 12 warnings (7 unmaintained / 4 unsound / 1 yanked). Grouped by package: wasmtime accounts for 16 of 34 vulns; the next-largest is aws-lc-sys at 5. The handoff doc's Cluster A (wasmtime 17 → 45) is the elephant by 3x over the next cluster. - Adds docs/vz-backend/cve-hygiene/audit-baseline-2026-05-26.json (134 KB) — the raw `cargo audit --json` output so a future reader can `jq` against the exact baseline. The BASELINE doc also explicitly retracts the original Step 2 prompt's cluster naming (pkcs8/rsa/ed25519-dalek as Cluster A, hyper/reqwest as Cluster B, serde/prost as Cluster C, etc.) — none of those crates appear in the actual 34-vuln list. The handoff doc's clustering, written against the live audit output during Phase 10 Day 1, is the one this branch follows. Branch context: - Branched off main@5b90ea8 (not from sash/local-test). Per the Phase 10.5 sign-off contract, the inherited-CVE work is intentionally isolated from the Mac substrate work; the two branches converge later via cherry-pick or merge after each is independently CI-green. - sash/local-test is untouched. main is untouched. - Cargo.lock unchanged at this commit (will be the first thing Day 1 touches, with the pkcs8 / ed25519-dalek peer-pin resolution). Operator verifier: git diff main..HEAD --stat # only docs/, no Cargo.toml or Cargo.lock cd elastos && cargo audit | tail -5 # reproduces 34 vulns + 12 warns Co-authored-by: Cursor <cursoragent@cursor.com>
Day 1 of Step 2 / Cluster C in RUNTIME_CVE_HANDOFF.md.
What this commit does:
- `cargo update` (workspace-wide) followed by two surgical `cargo
update --precise` rollbacks to keep the pkcs8 + ed25519 RC chain
pinned. Net effect: 14 vulnerabilities + 3 warnings closed by
patch-level + minor-level upstream releases that landed since
the lockfile was last touched. Zero new advisories introduced.
- Only `elastos/Cargo.lock` is modified. NO Cargo.toml changes,
NO source-code changes, NO new dependencies, NO removed peers.
Headline:
- Vulnerabilities: 34 -> 20 (closed 14, net -41%)
- Warnings: 12 -> 8 (closed 4, net -33%)
Closed advisories (full list):
- RUSTSEC-2026-0007 bytes 1.11.0 -> 1.11.1 (BytesMut::reserve overflow)
- RUSTSEC-2026-0009 time 0.3.46 -> 0.3.47 (stack-exhaustion DoS)
- RUSTSEC-2026-0037 quinn-proto 0.11.13 -> 0.11.14 (endpoint DoS)
- RUSTSEC-2026-0044 aws-lc-sys 0.37.0 -> 0.41.0 (X.509 name-constraints bypass)
- RUSTSEC-2026-0045 aws-lc-sys 0.37.0 -> 0.41.0 (AES-CCM timing side-channel)
- RUSTSEC-2026-0046 aws-lc-sys 0.37.0 -> 0.41.0 (PKCS7_verify chain bypass)
- RUSTSEC-2026-0047 aws-lc-sys 0.37.0 -> 0.41.0 (PKCS7_verify signature bypass)
- RUSTSEC-2026-0048 aws-lc-sys 0.37.0 -> 0.41.0 (CRL distribution scope error)
- RUSTSEC-2026-0049 rustls-webpki 0.103.9 -> 0.103.13 (CRL authoritativeness)
- RUSTSEC-2026-0067 tar 0.4.44 -> 0.4.46 (unpack_in chmod-via-symlink)
- RUSTSEC-2026-0068 tar 0.4.44 -> 0.4.46 (PAX size header ignored)
- RUSTSEC-2026-0098 rustls-webpki 0.103.9 -> 0.103.13 (URI name constraints)
- RUSTSEC-2026-0099 rustls-webpki 0.103.9 -> 0.103.13 (cert name constraints)
- RUSTSEC-2026-0104 rustls-webpki 0.103.9 -> 0.103.13 (CRL parser panic)
Closed warnings:
- core2 v0.4.0 (yanked + unmaintained) removed entirely
- rand v0.9.2 unsound advisory closed by rand 0.9.4 bump
Why the surgical rollback was needed:
A passive `cargo update` would have bumped `pkcs8 0.11.0-rc.11 ->
0.11.0` (stable). The stable release changed `Error::KeyMalformed`
from a unit variant to a tuple variant `KeyMalformed(KeyError)`.
`ed25519-dalek 3.0.0-pre.1` (transitively required by `iroh 0.96.1`
AND `iroh 0.97.0` -- the latest published iroh minor releases still
pin the pre-release ed25519) references the old unit variant in its
source; the build therefore fails if pkcs8 reaches stable.
Two `[patch.crates-io]` approaches were tried first:
1. `[patch] pkcs8 = "=0.11.0-rc.11"` -- rejected by cargo
("patches must point to different sources").
2. Pinning the iroh family forward to 0.97 -- doesn't help because
iroh 0.97 still pins ed25519-dalek 3.0.0-pre.1.
The third approach -- surgical `cargo update -p pkcs8 --precise
0.11.0-rc.11` and `cargo update -p ed25519 --precise 3.0.0-rc.4`
after the workspace-wide cargo update -- threads the needle: the
resolver accepts the lockfile, the crypto chain stays compilable,
and every other patch-level bump still lands.
Still-open vulnerabilities (next clusters):
- wasmtime 17.0.3: 16 advisories (Cluster A, requires 17 -> 24/36/42/43+ migration, multi-day project)
- wasmtime-wasi 17.0.3: 1 advisory (paired with Cluster A)
- hickory-proto 0.25.2: 2 advisories (Cluster D; one has no upstream patch)
- cap-primitives 2.0.2: 1 advisory (Cluster A-adjacent; requires major bump 2 -> 3)
Mac-sanity validation (this commit was built + tested on Darwin
arm64 host running cargo 1.89 / rustc 1.89.0):
- `cargo check -p elastos-common -p elastos-storage -p elastos-identity \
-p elastos-namespace -p elastos-tls -p elastos-compute` -> green
- `cargo test -p elastos-common -p elastos-storage -p elastos-identity \
-p elastos-namespace -p elastos-tls --lib` -> 138/138 ok
- `elastos-crosvm` is Linux-only and was not built locally (pre-existing
Darwin incompatibility, not introduced by this commit).
Linux/CI validation (operator should rely on ubuntu-latest workflow):
- `.github/workflows/ci.yml` runs `cargo check --workspace`, `cargo
test --workspace`, `cargo build --workspace --release` on
ubuntu-latest. Push of this branch triggers all three.
Reproduction (from main@5b90ea8):
git checkout -b experiment main
cd elastos
cargo update # ~221 lockfile moves
cargo update -p ed25519@3.0.0 --precise 3.0.0-rc.4
cargo update -p pkcs8@0.11.0 --precise 0.11.0-rc.11
cargo audit | tail -3 # 20 vulns, 8 warns
Co-authored-by: Cursor <cursoragent@cursor.com>
Companion to commit e3433a0 (cargo-update cascade). - DAY_1_NOTES.md: human-readable receipt of Day 1 work. Headline numbers, full closed-advisory table, surgical-rollback rationale, still-open vulnerabilities grouped by cluster, validation evidence (Mac sanity build + 138/138 tests passing), reproduction recipe. - audit-post-day1-2026-05-26.json: raw `cargo audit --json` after the cascade. Diffing this against audit-baseline-2026-05-26.json reproduces the +14 closed / 0 new delta. No code changes. Only docs + audit artefacts. Operator verifier: diff <(jq '.vulnerabilities.list[].advisory.id' \ docs/vz-backend/cve-hygiene/audit-baseline-2026-05-26.json \ | sort) \ <(jq '.vulnerabilities.list[].advisory.id' \ docs/vz-backend/cve-hygiene/audit-post-day1-2026-05-26.json \ | sort) | grep '^<' | wc -l # Expected: 14 (matches "closed by cascade" count) Co-authored-by: Cursor <cursoragent@cursor.com>
Outcome: zero bumps applied. Cluster B is done.
Findings:
- 10 of 11 TLS-chain crates at latest crates.io stable.
- 1 dual-version (webpki-roots 0.26.11 + 1.0.7) caused by ureq 2.x
in the shell capsule. Consolidation requires ureq 2 -> 3 major
bump with source-code changes (out of Day 2 scope).
- cargo audit confirms TLS chain is advisory-clean (0 hits across
rustls, rustls-webpki, webpki-roots, rustls-pemfile,
rustls-native-certs, tokio-rustls, hyper-rustls, hyper,
aws-lc-sys, aws-lc-rs, ring).
- All 20 remaining vulnerabilities are wasmtime (16), wasmtime-wasi
(1), hickory-proto (2), cap-primitives (1) — Clusters A and D.
Day 2 deliverables:
- DAY_2_NOTES.md: full pin audit, dual-version analysis, residual
explanation, before/after delta (0/0), operator one-liner verifier.
No code changes. No Cargo.toml changes. No Cargo.lock changes. Mac
sanity (cargo check + elastos-tls unit tests) re-confirmed green.
Pre-release versions (rustls 0.24-dev, rustls-webpki 0.104-alpha)
intentionally NOT adopted — Day 2 is a stability-focused hygiene
pass that stays on the crates.io stable channel.
Next: Day 3 (Cluster D — hickory-proto + cap-primitives).
Co-authored-by: Cursor <cursoragent@cursor.com>
…pdates)
Outcome: 3 Cluster D CVEs analyzed, 0 closed, 3 cleanly deferred.
Findings:
- RUSTSEC-2026-0119 (hickory-proto, CPU exhaustion via O(n^2) name
compression): patched at 0.26.1. BLOCKED by iroh 0.96.1/0.97.0
hard-pin `hickory-resolver = "^0.25.1"`. Deferred until iroh 1.0
stable or operator-approved fork.
- RUSTSEC-2026-0118 (hickory-proto, NSEC3 unbounded loop): same
blocking chain as #1; same iroh family hard-pin. Same deferral.
- RUSTSEC-2024-0445 (cap-primitives, Windows-only device-filename
sandbox bypass): patched at 3.4.1. BLOCKED by wasmtime-wasi 17.0.3
hard-pin `cap-std = "^2.0.0"`. Will CLOSE AUTOMATICALLY during
Cluster A migration (Days 4-8) when wasmtime-wasi bumps past 17.
Bump attempts and results:
$ cargo update -p hickory-resolver --precise 0.26.1
error: failed to select... required by package `iroh v0.96.1`
$ cargo update -p cap-primitives --precise 3.4.1
error: failed to select... required by package `wasi-common v17.0.3`
Both failed cleanly. Cargo.lock untouched. No partial-state risk.
Force-update mechanisms considered and rejected:
- [patch.crates-io] same-source: Cargo rejects (proven on Day 1).
- [patch.crates-io] git fork: out of scope (new dep source).
- iroh 0.97 -> 1.0.0-rc.0: pre-release; violates Day 2 stable-
channel discipline.
- wasmtime 17 -> 24+: scoped to Cluster A on Days 4-8.
Day 3 deliverables:
- DAY_3_NOTES.md: per-advisory analysis, blocking-chain trees,
bump-attempt evidence, deferral disposition, cross-cluster status
table, recommendations for Day 4 handoff.
No code changes. No Cargo.toml changes. No Cargo.lock changes.
Mac/Linux risk note on RUSTSEC-2024-0445: advisory is Windows-only.
ElastOS Mac substrate and elastos-runtime Linux substrate do not run
on Windows; risk to current deployment profile is effectively zero.
Advisory still counts in cargo audit totals; closing it is correct
hygiene even if not exploitable in our target deployment.
Cluster status across Step 2:
C (cascade) Day 1 DONE 14 closed
B (TLS residual) Day 2 DONE 0 closed (cluster exhausted by D1)
D (hickory+cap) Day 3 DONE 0 closed, 3 deferred
A (wasmtime) Day 4-8 PENDING est. 17 + auto-close of cap-primitives
E (unmaintained) Day 9 PENDING warnings only
Projected at-completion: 31 of 34 CVEs closed. Residual = 2 hickory-proto
unless iroh 1.0 lands stable mid-cycle.
Next: Day 4 (Cluster A wasmtime migration, day 1 of 5).
Co-authored-by: Cursor <cursoragent@cursor.com>
Outcome: 0 CVEs closed Day 4. Bump probed and cleanly reverted. Multi-day
plan for Days 5-8 documented based on evidence from the probe.
Investigation:
- Touch-point inventory: ~15 wasmtime API call sites, all in ONE file
(elastos/crates/elastos-compute/src/providers/wasm.rs).
- Version-step ladder + CVE coverage projection:
24.0.9 closes 12 of 17 wasmtime CVEs
36.0.10 closes ALL 17 (5 require >=36)
45.0.0 same as 36+ for CVE count; bigger API delta
Bonus: wasmtime-wasi past 17 auto-closes cap-primitives Cluster D CVE
via cap-std major bump.
Probe (17 -> 24) executed in 5 steps:
1. Pinned wasmtime + wasmtime-wasi to "24" in elastos-compute/Cargo.toml.
2. cargo update resolved cleanly to 24.0.9.
3. cargo build -p elastos-compute surfaced 4 API errors -- 3 mechanical
(wasmtime_wasi::sync module removed; WasiCtx renamed to WasiP1Ctx
in preview1 module; add_to_linker moved to preview1::add_to_linker_sync;
Dir::open_ambient_dir replaced by WasiCtxBuilder::preopened_dir).
4. STRUCTURAL BLOCKER discovered:
wasmtime-wasi 24's WasiP1Ctx does NOT expose insert_file(fd, file, mode).
Our carrier bridge at wasm.rs:221-230 injects ReadPipe/WritePipe at
custom fds 3 and 4 via wasi-common 17's API. This pattern has no
direct equivalent in wasmtime-wasi 24's preview1 module.
5. Cleanly reverted: Cargo.toml restored, Cargo.lock rolled back to
wasmtime 17.0.3, working tree byte-identical to start of Day 4.
Three forward paths for Days 5-8:
Path 1 (RECOMMENDED for Day 5):
Keep wasi-common 17 as standalone crate alongside wasmtime-wasi 24.
Probe whether the Linker<WasiCtx> setup still works cross-crate.
If yes: wasmtime 24 lands in Day 6, Day 7 attempts 24 -> 36, Day 8
re-audits to project 32 of 34 CVE closure.
Path 2 (Day 5 fallback if Path 1 fails):
Rewrite carrier bridge to use stdio multiplex instead of custom fds.
Substantial: affects wasm.rs AND likely the capsule SDK side. Multi-day.
Path 3 (Worst case):
Full preview2 component-model migration. Multi-week. Out of Step 2 scope.
Evidence captured for Days 5-8:
- Per-CVE patched-version table.
- Day 4 attempt logs (4 error classes, file:line for each).
- Reproducer for the cliff (insert_file grep on wasmtime-wasi 24 source).
Cluster status across Step 2 (no movement from Day 3):
C (cascade) Day 1 DONE 14 closed
B (TLS residual) Day 2 DONE 0 closed (exhausted by D1)
D (hickory + cap) Day 3 DONE 0 closed, 3 deferred
A (wasmtime) Day 4 PROBE 0 closed, multi-day plan for 5-8 documented
E (unmaintained) Day 9 PEND 0 (warnings only)
Projection range at Step-2-end:
Optimistic: 32 of 34 closed (residuals = 2 hickory-proto)
Pessimistic: 14 of 34 closed (Cluster A cliff blocks; operator decision)
No code changes Day 4. No Cargo.toml changes Day 4 (probe restored).
No Cargo.lock changes Day 4 (probe restored). Mac sanity (elastos-compute
build) re-confirmed green.
Next: Day 5 (Path 1 probe -- wasi-common 17 standalone compatibility with
wasmtime 24's Linker<WasiCtx>).
Co-authored-by: Cursor <cursoragent@cursor.com>
…mismatch)
Outcome: 0 CVEs closed Day 5. Path 1 (wasi-common 17 coexistence with
wasmtime 24) ruled out via a single-error build probe. Working tree
restored to byte-identical baseline.
Probe (executed and reverted in-session):
- Cargo.toml: wasmtime 17->24, wasmtime-wasi 17->24, added
wasi-cap-std-sync=17 and wasmtime-wasi-17={package="wasmtime-wasi",
version="17", features=["sync"]} as aliased coexistence deps.
- wasm.rs: rewrote 4 import/call sites (WasiCtxBuilder -> wasi_cap_std_sync,
WasiCtx -> wasi_common, Dir+ambient_authority -> wasi_cap_std_sync,
add_to_linker -> wasmtime_wasi_17::sync, I32Exit -> wasi_common).
- cargo build -p elastos-compute: ONE error (E0308 mismatched types):
"expected `&mut Linker<WasiState>`, found `&mut Linker<_>`
wasmtime::Linker<_> and wasmtime::linker::Linker<_> have similar
names, but are actually distinct types
wasmtime 24.0.9::Linker vs wasmtime 17.0.3::Linker"
Why Path 1 is structurally impossible:
wiggle's wasmtime_integration! macro in wasmtime-wasi 17 generates
add_to_linker(linker: &mut Linker<T>, ...) where Linker comes from
whichever wasmtime crate was in scope at wasmtime-wasi 17's compile
time -- i.e. wasmtime 17. When the workspace also has wasmtime 24
as a direct dep, the wasm.rs code's `Linker::new(engine)` resolves
to wasmtime 24's Linker. Different crate versions = different types
in Rust's nominal type system. No trait coercion, [patch], or
feature flag can bridge this.
Generalization: any plan that requires coexisting wasmtime 17 and
wasmtime 24 in the same workspace, with code that passes a Linker<T>
between them, is structurally impossible. Path 1 and all
"compatibility shim" variants are dead. Either bump the entire
wasmtime+wiggle+wasi-common cluster together, or stay on 17.
Reverted state (all byte-identical to start of Day 5):
- Cargo.toml: wasmtime=17, wasmtime-wasi=17, wasi-common=17 (no
wasi-cap-std-sync, no wasmtime-wasi-17 alias).
- wasm.rs: restored via git checkout.
- Cargo.lock: dropped wasmtime/wasmtime-wasi 24.0.9; restored
fully via git checkout (caught minor windows-sys 0.61->0.60
ripple from the cascade).
- cargo check -p elastos-compute: green (0.54s incremental).
- cargo audit: 20/8 unchanged.
Forward options collapse to:
Path 2 (RECOMMENDED, Day 6): rewrite carrier bridge to use stdio
multiplex or side-channel protocol instead of custom-fd injection.
Then bump wasmtime cleanly. Day 6 = design memo; Day 7 = impl;
Day 8 = bump+verify.
Path 3: full preview2 component-model migration. Multi-week, out
of scope.
Path 4 (new option after Day 5): accept 17 wasmtime CVEs as known
residual. Document risk. Ship alpha with caveat. Operator decision.
Day 6 produces a Path 2 design memo. Operator reviews. If approved,
Days 7-8 implement. If not, Day 6 pivots to Path 4 acceptance memo
and Days 7-9 reallocate to Cluster E + early sign-off.
Cluster status (no movement from Day 4):
C (cascade) Day 1 DONE 14 closed
B (TLS residual) Day 2 DONE 0 closed (exhausted by D1)
D (hickory + cap) Day 3 DONE 0 closed, 3 deferred
A (wasmtime) Day 4-8 IN_PROGRESS 0 closed, Day 6 = Path 2 or Path 4 decision
E (unmaintained) Day 9 PENDING 0 (warnings only)
Projection ranges narrowed:
Path 2 success: 32 of 34 closed (Day 8 finish)
Path 2 partial: 14-26 of 34 closed (operator decision required)
Path 4: 14 of 34 closed + documented residual + early sign-off
Co-authored-by: Cursor <cursoragent@cursor.com>
Outcome: 2 new docs (~400 lines). Zero source/Cargo/lockfile changes.
Day 7 branches on operator's Path 2A vs Path 4 decision.
Day 6 work:
1. Read the carrier-bridge wire contract end-to-end:
- Host: elastos-compute/src/providers/wasm.rs (lines 35-238)
- SDK: elastos-guest/src/runtime.rs (lines 219-618)
- Wire format: line-based newline-terminated UTF-8 JSON envelopes
- Discovery: ELASTOS_CARRIER_FDS=3,4 env var (WASM bridge),
ELASTOS_CARRIER_PATH=/dev/hvc0 (microVM virtio-console),
ELASTOS_API+TOKEN (HTTP), or stdio (standalone)
2. Discovered critical design constraint:
stdio is INTENTIONALLY preserved for user I/O (per wasm.rs:95
design comment). Any Path 2 rewrite must preserve stdio while
finding a different transport for the bridge. This rules out
"multiplex over stdio" as a candidate.
3. Enumerated four forward options and scored each on 5 axes
(host/SDK LOC, wire-format change, fork burden, effort, risk):
Path 2A: Two FIFOs in preopened directory (RECOMMENDED)
Path 2B: Fork wasmtime-wasi 24 with insert_file restored
(rejected: permanent maintained-fork burden)
Path 2C: Single Unix-domain socket via CARRIER_PATH
(rejected: open(2) on Unix-socket files fails on Linux
in WASI preview1 -- would need separate sandbox-policy
work)
Path 4: Accept residual (legitimate alternative)
4. Authored PATH_2_DESIGN_MEMO.md (operator decision document):
- Wire-contract description on both sides
- Three Path-2 sub-options with pros/cons/effort
- Path 4 with engineering-vs-security trade-off
- Test plan for Path 2A
- Operator-scannable decision matrix
- Two pre-written Day 7 prompt scaffolds (for "chose 2A" and
"chose 4")
5. Authored DAY_6_NOTES.md (investigation trail + handoff).
Operator decision point reached. Day 7 launches one of:
- Path 2A implementation (3 commits: host FIFO plumbing, SDK
detection, wasmtime 17->24 bump + 4 mechanical source rewrites)
- Path 4 acceptance (1 doc + Cluster E pivot)
Projection ranges:
Path 2A success: 32 of 34 CVEs closed (Day 8)
Path 2A degraded: 26 of 34 (24->36 hop blocked, residual = 5+2)
Path 4: 14 of 34 closed + documented residual
No code changes. No Cargo.toml changes. No Cargo.lock changes.
Mac sanity unchanged (no build needed for docs-only day).
Co-authored-by: Cursor <cursoragent@cursor.com>
Lands the wasmtime-24-compatible FIFO carrier-bridge transport
alongside the legacy fd-injection transport. Both work; default
stays Fds for back-compat. Day 8 flips the default to Fifos and
bumps wasmtime 17->24 to close 12+ CVEs.
What changed
============
Host (elastos-compute/src/providers/wasm.rs):
* BridgeTransport::{Fds, Fifos} enum + set_bridge_transport setter.
Default is Fds; runtime opts in to Fifos.
* setup_carrier_fifos(): mkfifo two FIFOs in a per-launch
/tmp/elastos-carrier/<capsule-id>/ dir (mode 0700), opens both
host-side ends O_RDWR | O_CLOEXEC (mode 0600 on FIFOs).
O_RDWR anchors the FIFOs so capsule-side opens succeed without
a handshake thread; EOF-on-write detection still works via EPIPE.
* build_wasi_context() now dispatches on transport: Fifos preopens
the carrier dir at /_carrier and sets ELASTOS_CARRIER_FIFOS env
var; Fds keeps the existing insert_file path unchanged.
* RunningInstance.carrier_dir + Drop impl: defensive cleanup of
the FIFO dir on instance drop (covers stop() AND panic paths).
* Error-path cleanup on preopen failure to prevent dir leaks.
SDK (elastos-guest/src/runtime.rs):
* channel_from_fifos(): opens reader RDONLY + writer WRONLY by
path; wraps as CarrierChannel::FilePair. Same wire format
(line-based JSON envelopes) as channel_from_fds().
* RuntimeClient::new() detection order updated:
ELASTOS_CARRIER_FIFOS -> _FDS -> _PATH -> HTTP -> stdio.
Capsule code unchanged; pure env-var routing.
* Deprecated docstring added to channel_from_fds (kept as
back-compat fallback for one release).
Tests
=====
9 new tests, all passing:
Host (elastos-compute, 5 new):
* test_set_bridge_transport_round_trip
* test_setup_carrier_fifos_creates_dir_and_fifos_with_correct_modes
* test_cleanup_carrier_dir_is_idempotent
* test_setup_carrier_fifos_round_trip_via_host_ends (END-TO-END
JSON envelope round-trip; byte-identical to fd-injection format)
* test_mkfifo_returns_typed_error_on_invalid_path
* test_running_instance_drop_cleans_carrier_dir
SDK (elastos-guest, 4 new):
* channel_from_fifos_rejects_missing_env
* channel_from_fifos_rejects_malformed_env (4 input shapes)
* channel_from_fifos_round_trip (END-TO-END)
* runtime_client_new_prefers_fifos_over_fds (uses garbage
_FDS value to prove _FIFOS code path is hit FIRST)
Verifier matrix
===============
cargo test -p elastos-compute --lib : 10/10 pass (5 new + 5 old)
cargo test -p elastos-guest --lib : 13/13 pass (4 new + 9 old)
cargo check -p elastos-compute --tests : green
cargo check -p elastos-guest --tests : green
cargo audit : 20/8 (unchanged from Day 6;
zero dep changes by design)
Linux cross-build : blocked by missing cross-gcc
(same gap as Phase 10.6)
Day-1 cascade collateral fix
============================
While running the SDK test verifier, found a pre-existing build
failure at runtime.rs:1207 — Day 1's Cluster-C cascade bumped libc
0.2 which changed openpty()'s last two params from *const to *mut.
Fixed: two `null()` -> `null_mut()` calls. Added a code comment
explaining the libc 0.2 API change. This unblocks Day 7 SDK tests
and restores test_runtime_client_two_calls_over_tty_serial which
has been broken since Day 1.
NOT scope creep: caused by Day 1, blocks Day 7 verification, fix
is one-character mechanical.
Day 7 CVE delta
===============
0 by design. Day 8 (wasmtime 17 -> 24) closes 12.
What this commit does NOT do
============================
* Does NOT touch wasmtime version. Day 8.
* Does NOT change default transport (stays Fds). Day 8.
* Does NOT remove insert_file calls. Day 8.
* Does NOT modify BridgePipes consumer contract.
* Does NOT touch supervisor.rs, carrier_bridge.rs, or elastos-vz.
See docs/vz-backend/cve-hygiene/DAY_7_NOTES.md for full detail.
Co-authored-by: Cursor <cursoragent@cursor.com>
…VEs) Closes 12 of the 17 inherited wasmtime CVEs and brings the elastos-compute crate onto the upstream wasmtime + wasmtime-wasi 24.0.9 stack. Made possible by Day 7's FIFO carrier-bridge transport (commit 1d8b781), which removed our dependency on wasi.insert_file() — the API the upstream 24 release deleted. Audit delta =========== Before: 20 vulnerabilities, 8 warnings, 718 deps After: 8 vulnerabilities, 6 warnings, 713 deps Delta: -12 vulns, -2 warns, -5 deps What changed ============ elastos-compute/Cargo.toml: - wasi-common = "17" (dropped; no longer used) - wasmtime = "17" -> wasmtime = "24" - wasmtime-wasi = "17" -> wasmtime-wasi = "24" elastos-compute/src/providers/wasm.rs (net -171 lines): * Imports: - wasi_common::pipe::{ReadPipe, WritePipe} (removed) - wasmtime_wasi::sync::WasiCtxBuilder (moved to top-level) - wasmtime_wasi::WasiCtx (replaced by preview1::WasiP1Ctx) + wasmtime_wasi::preview1::{self, WasiP1Ctx} + wasmtime_wasi::{DirPerms, FilePerms, WasiCtxBuilder} * BridgeTransport::Fds variant REMOVED. Only Fifos remains; it is the default. wasmtime-wasi 24+ has no insert_file, so fd-injection is structurally impossible. * CARRIER_READ_FD / CARRIER_WRITE_FD constants REMOVED. * create_pipe() helper REMOVED. * All wasi.insert_file() calls REMOVED. * build_wasi_context() dispatch collapsed: only the FIFO path remains. * `Dir::open_ambient_dir` + 2-arg `preopened_dir(cap_dir, "/path")` REPLACED by the new 4-arg `preopened_dir(host_path, "/guest_path", DirPerms, FilePerms)` API. Centralised perm-flag translation in a new `wasi_perms(has_read, has_write)` helper. * builder.args/env now infallible (returns &mut Self) — dropped the .map_err(...)? chains throughout. * builder.build() -> builder.build_p1() (preview1-specific build). * wasmtime_wasi::add_to_linker -> preview1::add_to_linker_sync. * Tests: - test_create_pipe (REMOVED; helper is gone) - test_set_bridge_transport_round_trip -> test_default_bridge_transport_is_fifos (Fds variant gone, so the test asserts the new default and idempotent self-assignment instead) Verifier matrix =============== cargo test -p elastos-compute --lib : 9/9 pass on wasmtime 24 cargo test -p elastos-guest --lib : 13/13 pass (untouched today) cargo audit : 8/6 (down from 20/8) cargo check -p elastos-server : blocked by pre-existing Mac /elastos-crosvm gap (Phase 10.6) Public-API impact ================= Removed `BridgeTransport::Fds` variant. Verified zero external consumers (grep across the workspace finds only the two files I modified). No public-API break for any downstream crate. Residual CVEs after Day 8 ========================== 8 total: * 6 wasmtime 24 — 5 are Winch-only (we don't enable Winch); 1 is aarch64 Cranelift (medium risk). All would close at wasmtime 36+. * 2 hickory-proto — blocked by iroh hard-pin (documented Day 3). Cluster A complete. Step 2 progress: 26 of 34 CVEs closed (76%). See docs/vz-backend/cve-hygiene/DAY_8_NOTES.md for full detail including per-CVE risk classification. Co-authored-by: Cursor <cursoragent@cursor.com>
Bonus Cluster A day; fully closes the wasmtime CVE cluster. Bumps wasmtime + wasmtime-wasi from 24 → 36 in elastos-compute/Cargo.toml. Zero source changes required — the API surface used by elastos-compute (WasiP1Ctx, preview1::add_to_linker_sync, WasiCtxBuilder::preopened_dir, DirPerms / FilePerms) has been stable across the 24..36 release line. All 22 tests pass on the new stack with the exact same wasm.rs we shipped on Day 8. CVE delta: 8 vulns → 2 vulns. The 6 closed are all wasmtime CVEs (RUSTSEC-2026-0086/0088/0089/0094/0095/0096), including one medium-severity aarch64 Cranelift sandbox issue (RUSTSEC-2026-0096) and one medium-severity Winch fuzz panic (RUSTSEC-2026-0088). The 2 remaining are both hickory-proto, blocked by an iroh hard-pin and already documented as deferred on Day 3. Step 2 progress: 32/34 = 94% CVE closure from baseline. Cargo.lock churn is net negative (−47 lines); wasmtime 36 has a slightly leaner transitive tree than 24 in our config. Full notes: docs/vz-backend/cve-hygiene/DAY_9_NOTES.md Co-authored-by: Cursor <cursoragent@cursor.com>
… 2 dead deps)
Reduces cargo audit warnings from 6 to 4 by closing the two we
actually own end-to-end:
- RUSTSEC-2026-0002 (lru 0.12.5 unsoundness) — closed by bumping
elastos-storage's direct lru dep 0.12 → 0.18 *and* removing the
unused `ratatui` declaration from elastos-server/Cargo.toml, which
was the only other in-tree consumer of lru 0.12. lru 0.12.5 is
fully gone from the dependency tree.
- RUSTSEC-2025-0134 (rustls-pemfile 2.2.0 unmaintained) — closed
by bumping axum-server 0.7 → 0.8 (which dropped its transitive
rustls-pemfile dep) *and* migrating elastos-tls's call sites
from `rustls_pemfile::{certs, pkcs8_private_keys}` to the
in-tree `rustls_pki_types::pem::PemObject` API (re-exported
under tokio_rustls::rustls::pki_types::pem). Wire format and
return types are identical.
Also removes `ratatui = "0.29"` and `crossterm = "0.28"` from
elastos-server/Cargo.toml — both were declared but never imported
anywhere in source. Their removal pulls a ~207-line Cargo.lock
reduction (signal-hook, mio variants, parking_lot duplicates).
The 4 remaining warnings (atomic-polyfill, bincode 1.3, fxhash,
paste) are all transitive in the iroh/wasmtime/postcard ecosystems
or behind a deliberate wire-format boundary (bincode → token
encoding). Each is documented as a Day-3-style defer with an
unblock condition in DAY_10_NOTES.md.
Verifier matrix (all green):
- cargo test -p elastos-storage --lib → 42 passed
- cargo test -p elastos-tls --lib → 4 passed
- cargo test -p elastos-compute --lib → 9 passed
- cargo test -p elastos-guest --lib → 13 passed
Total: 68/68 tests pass on the leaner stack.
Step 2 progress: 32/34 CVEs closed (94 %) + 2 warnings closed.
Full notes: docs/vz-backend/cve-hygiene/DAY_10_NOTES.md
Co-authored-by: Cursor <cursoragent@cursor.com>
Closes Step 2 of the inherited-CVE remediation work on chore/runtime-cve-hygiene. Three new docs + one updated: - cve-hygiene/RUNTIME_CVE_HYGIENE_SIGNOFF.md (NEW): full closure narrative covering 11 working days, 12 commits, 32/34 CVE closure (94%), 2/6 warning closure, residual deferrals with named follow-up branches, reviewer checklist. - cve-hygiene/MERGE_PLAN.md (NEW): Option A (recommended) vs Option B sequencing for merging this branch into main; anticipated reviewer Q&A; rollback plan with per-day revert units; post-merge cargo audit baseline expectations. - cve-hygiene/final-audit-2026-05-27.json (NEW): live cargo audit --json snapshot captured at branch HEAD (ce8c1e4). 685 deps scanned, 2 vulns (both hickory, iroh hard-pinned), 4 warnings (all transitive in upstream ecosystems or behind wire-format boundary). - vz-backend/RUNTIME_CVE_HANDOFF.md (UPDATED): added top-level COMPLETED status banner with branch HEAD, closure tally, and doc cross-references. Added per-cluster closure-status callouts (A: closed, B: closed via cascade, C: closed, D: partial, E: partial) so the historical day-0 plan now self-documents what landed and what was deferred. This is a doc-only commit. No code, no Cargo.toml, no Cargo.lock changes. Branch is now ready for review against main. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 26, 2026
Closes PHASE_10_6_GAP_REPORT.md Issue #2 (supervisor.rs:1019 E0609 'no field prune_orphans_on_startup on type VzConfig'). The Linux-side block at supervisor.rs:1016-1021 mirrors the Mac-side orphan-prune control flow (lines 997-1015) but as a no-op. The line `let _ = vz_config.prune_orphans_on_startup;` exists to keep the read-shape identical across both platforms; it was unbuildable because the Linux vz_stubs::VzConfig was a unit struct with no fields. Fix: convert vz_stubs::VzConfig from a unit struct to a struct with a single `pub prune_orphans_on_startup: bool` field, default false. Zero runtime effect on Linux (the field is read inside a discarded binding); makes the file compile under the Linux build target. Lower-blast-radius option per the gap report. Verification: - cargo check -p elastos-server (Mac) → green (only pre-existing unrelated dead_code warning in overlay_initrd.rs) - Linux side: addresses one of the 6 E0609/E0433 errors logged by gh run 26462677776 against commit 3be4d0a Remaining gap-report issues: - #1 (doctor_cmd.rs field-access cluster) — next commit - #3 (elastos-vz/src/vm.rs unused-import audit) - #4 (clippy manual_find in concurrent_launch.rs:464) Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 26, 2026
Closes PHASE_10_6_GAP_REPORT.md Issue #1 (doctor_cmd.rs E0433 + 4× E0609 errors at lines 105/114/172/173/232). The function reads four absolute paths off elastos_vz::VzConfig (kernel_path, initramfs_path, state_dir, rootfs_cache_dir) and calls elastos_vz::VzConfig::new().with_kernel_path(...).validate() for a guest-kernel sanity check. None of those types or methods exist on Linux because `elastos-vz` is a Mac-only target.dependency. Fix (gap report's recommended approach): cfg-gate the entire print_report body to Mac, with a Linux stub that prints vz substrate: not available on this platform (Mac-only) doctor inspects elastos-vz artifacts (kernel, initrd, state_dir, rootfs_cache_dir); nothing to report on Linux. …and returns Ok so `elastos doctor` exits 0 on Linux cleanly. This matches the original cross-OS intent (doctor inspects the Vz substrate; on Linux there is no Vz substrate to inspect) and avoids the "alternative" approach of extending vz_stubs::VzConfig with placeholder fields that would print meaningless empty paths. Public signature unchanged (same `pub(crate)` visibility, same args, same return type) — both cfg branches have identical shapes so callers don't need cfg-gating. Verification: - cargo check -p elastos-server (Mac) → green - cargo test -p elastos-server --lib doctor_cmd:: → 5/5 pass - Linux side: closes 5 of the 6 errors logged by gh run 26462677776 Remaining gap-report issues: - #3 (elastos-vz/src/vm.rs unused-import audit) - #4 (clippy manual_find in concurrent_launch.rs:464) Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 26, 2026
Closes PHASE_10_6_GAP_REPORT.md Issue #4 (concurrent_launch.rs:464 clippy::manual_find under -D warnings on Mac Vz CI). The latent lint existed before Phase 10.6 but surfaced fresh after fix1's cargo-fmt commit invalidated clippy's cached analysis. The test helper `observed_boot_markers` was using an explicit `for ... { if ... { return Some(...) } } None` pattern which clippy recognises as a manual reimplementation of Iterator::find. Fix (clippy's suggestion): MARKERS.iter() .find(|&marker| lines.iter().any(|l| l.contains(marker))) .copied() Same semantics, idiomatic, no behavioural change to the test. Verification: - cargo clippy -p elastos-vz --tests -- -D warnings → green - Mac side: closes the only clippy hard-error on Mac Vz CI - Linux side: clippy ran clean on the touched file too (only -D warnings issue on Linux was the unused-import in vm.rs, fixed in the previous commit) All four PHASE_10_6_GAP_REPORT.md issues now closed: - #1 doctor_cmd.rs print_report cfg-gate - #2 supervisor.rs prune_orphans_on_startup stub field - #3 vm.rs unused VzError import cfg-gate - #4 concurrent_launch.rs manual_find Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 26, 2026
CI on the previous 4-commit push (gh run 26468690747) surfaced two
additional Linux-reachable `elastos_vz::*` sites that the gap report
explicitly warned about ("audit ALL files, not just the obvious one"):
(a) doctor_cmd.rs:272 — inside `print_artifact_row`, NOT print_report.
Fixed in commit 3ef99d6: I cfg-gated `print_report` itself but the
helper `print_artifact_row` still references `elastos_vz::VzConfig`
on Linux even though the only Linux caller is the stub (the function
body is type-checked regardless of reachability).
Fix: wrap just the validate-probe block in `#[cfg(target_os = "macos")]`.
(b) supervisor.rs:4328 — Linux-only test
`supervisor_new_is_noop_on_linux_even_with_prune_flag_set` (added in
Phase 5 Day 4) explicitly used the `elastos_vz::` namespace path:
elastos_vz::VzConfig::new().with_prune_orphans_on_startup(true)
On Linux that path doesn't resolve. The other Linux-only test at
line 4068 was OK because it used the file-local `VzConfig` alias.
Fix: switch to the alias (`VzConfig::new()…`) so the test uses
`vz_stubs::VzConfig` on Linux and `elastos_vz::VzConfig` on Mac;
extend the stub with a `with_prune_orphans_on_startup(bool)` builder
to match the Mac surface the test exercises.
Pre-push audit of remaining `elastos_vz::` references in
elastos-server/src/ confirms all other sites are already inside
`#[cfg(target_os = "macos")]` modules, functions, or test blocks
(vm_debug_cmd.rs uses `#[cfg(target_os = "macos")] mod macos`;
run_cmd.rs uses cfg-gated `run_microvm_standalone`; main.rs uses
cfg-gated provider registration; the ~20 test-side imports are all
inside Mac-only tests).
Verification:
- cargo check -p elastos-server (Mac) → green
- Linux side: will be confirmed by CI on this push
All four PHASE_10_6_GAP_REPORT.md issues remain closed; this commit
just patches two Linux sites the original Issue #1 fix missed.
Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 26, 2026
All four PHASE_10_6_GAP_REPORT.md issues are now resolved on this branch (HEAD 5d754b8) and all three CI lanes are green: - Linux-untouched gate (Vz backend) → success (11s) - CI (Linux build + clippy -D warnings + tests) → success (2m36s) - Mac Vz CI (Apple Silicon, threads=1 & 4) → success (15m54s) PHASE_10_5_SIGNOFF.md: - Retraction banner replaced with a closure banner that lists the current CI status per lane. - The "⚠️ See the branch-status callout above" suffix on the original Outcome paragraph is removed (the caveat no longer applies). PHASE_10_6_GAP_REPORT.md: - Header status flipped from "PAUSED — partial completion" to "✅ CLOSED — All four issue classes resolved in Phase 10.7." - New "Phase 10.7 closure record" section at the bottom catalogs the 7 closure commits, the final CI state, per-issue cost delta (~75 min estimated vs ~145 min actual), the sign-off-discipline checklist that corrects the Phase 10.5 gap (each fix is its own commit, Cargo.lock untouched, no new deps, CI green before closure), and the test-coverage delta. Both documents now reflect reality: the branch is honest about what was unresolved, what got resolved, what each fix cost, and that closure required the same sign-off discipline the original Phase 10.5 sign-off lacked. This closes both PHASE_10_5 and PHASE_10_6/10.7 doc-side and makes the branch ready for reviewer. Merge sequencing relative to the inherited-CVE branch (PR #1) is the reviewer's call. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 27, 2026
The previous team-shared version of BRANCH_SUMMARY.md was point-in-time accurate through Phase 9 sign-off with Phase 10 (CVE audit) on Day 1. Since then we've landed: - Phase 10 (full Mac-substrate security hardening — closed) - Phase 10.5 (M1-M4 medium-severity findings — all 4 closed) - Phase 10.6 (substrate-CI cleanup — paused with gap report) - Phase 10.7 (gap-report closure — all 4 issues fixed, 3/3 CI lanes green) - Parallel `chore/runtime-cve-hygiene` (32 of 34 inherited CVEs closed, PR #1 open against `main`) Changes in this commit: 1. Replaced the stale 2026-05-26 "Substrate-CI red" retraction banner at the top with a "What's new since the team last saw this doc" table that lists Then/Now status for each of the 7 tracks above plus the current 3/3 green CI status on HEAD 2766a5a. Includes a one-line update operators can paste into Slack to summarize. 2. Rewrote the Executive summary so it reads correctly from a fresh team member's point of view (security posture has moved on substantially; 3/3 CI lanes green; CVE remediation 94% complete on parallel branch). 3. Updated the "At a glance" metrics table: dropped stale "commits ahead of main" (we're past 72), added HEAD sha, added Phase 10/10.5/10.6/10.7 sign-off rows, added current CI status row, added parallel CVE-branch row. 4. Replaced the security section's "what is not done" table with a two-table split: - "What has been done since the team last saw this doc" (8 rows, all ✅ with anchors to the closing artifacts) - "What is still not done" (6 rows, narrower scope, headlined by the external-code-review of `elastos-vz`) Updated the "MUST FIX before public release" list: items 1 and 2 are now struck through (DONE), item 3 (external code review) is the sole remaining must-fix. 5. Rewrote "Recommended next phase" from the original Phase-10 plan (now closed) to the actual recommended sequence going forward: merge PR #1 first, then open a PR for sash/local-test, then Phase 11 (external review window + M5 deferred fuzz target + VM memory-zero verification + sign+notarize CI wiring). 6. Updated TL;DR and the one-line verdict to reflect 2026-05-27 reality: engineering done, internal security work done, CI green, the only remaining gate to public ship is external code review. 7. Refreshed the anchors list at the bottom: added PHASE_10_SIGNOFF, PHASE_10_5_SIGNOFF, PHASE_10_6_GAP_REPORT (now CLOSED), the new cve-hygiene/ sign-off and merge plan, and the PR #1 URL. Net: +122/-79. No content was removed that's still accurate (the For-engineers section, the architectural shape diagram, the FAQ, the entitlements table, the engineer quickstart, and the known-engineering-gaps table are all preserved unchanged). This document is now the single shareable summary the team should read to understand the current state of the branch. Co-authored-by: Cursor <cursoragent@cursor.com>
…ype-complexity PR #1 (chore/runtime-cve-hygiene → main) CI surfaced four classes of issue that local `cargo test` did not catch because the workspace gates `cargo fmt --check`, `cargo clippy -- -D warnings`, and `cargo build --release` were not part of my Step 2 verifier matrix. Fixed in-place: - cargo fmt: 3 sites in crates/elastos-compute/src/providers/wasm.rs (Day 7 FIFO carrier work), 1 site in crates/elastos-guest/src/runtime.rs, 1 site in crates/elastos-tls/src/lib.rs (Day 10 PEM migration). - generic-array 0.14.9 deprecation cascade (Step 2 Day 1 cargo-update brought in 0.14.9 which marks GenericArray::as_slice / from_slice deprecated as a forward-looking signal for the eventual 1.x migration): * crates/elastos-namespace/src/resolver.rs:300,714,732 — switched to `&digest[..]` (Deref<Target = [u8; 32]>), fully forward-compatible with generic-array 1.x. * crates/elastos-identity/src/store.rs:203,229 — `#[allow(deprecated)]` on the Nonce::from_slice bindings, with a comment explaining the migration is deferred until aes_gcm upstream publishes a generic-array 1.x release. * capsules/localhost-provider/src/main.rs:144,186 — same treatment. - clippy::type_complexity in WasmProvider::build_wasi_context — factored the 4-tuple return type into a `WasiContextWithBridge` type alias near the BridgePipes definition. Verifier matrix (local, Mac): * cargo fmt --all -- --check → clean * cargo clippy -p elastos-{namespace,identity,compute} -p localhost-provider --all-targets -- -D warnings → clean * cargo test -p elastos-{namespace,identity,compute} -p localhost-provider → 18+ passing (sha2/aes_gcm crypto round-trips green) * cargo build -p elastos-namespace --release → clean Sign-off discipline note: I previously claimed PR #1 was merge-ready based on local `cargo test` only; that was incomplete. Going forward the Step 2 verifier matrix is being amended to mirror the Linux CI gate exactly (fmt --check, clippy -D warnings, build --release, test) before any "ready for review" claim. Co-authored-by: Cursor <cursoragent@cursor.com>
…/0.97 split PR #1 CI surfaced 5 type-mismatch errors in elastos-server because two versions of iroh/iroh-gossip/iroh-base ended up in the dep graph: elastos-server ─┬─ iroh 0.96.1 (direct, pinned) └─ distributed-topic-tracker 0.2.8 └─ iroh 0.97.0 (transitive — silent bump) distributed-topic-tracker 0.2.8 (released 2026-03-18) silently bumped its iroh dep from ^0.96 to ^0.97. This clashed with our direct iroh 0.96 pin and produced E0308/E0599 errors of the form: expected `iroh_gossip::net::Gossip`, found `iroh_gossip::Gossip` no method `subscribe_and_join_with_auto_discovery_no_wait` found for struct `iroh_gossip::Gossip` in the current scope Pinned distributed-topic-tracker to "=0.2.7" — the last 0.2.x release on iroh ^0.96 (verified via crates.io API). Cargo.toml comment documents the constraint so a future cargo update --aggressive cannot silently re-introduce the conflict, and tracks "migrate elastos-server to iroh 0.97" as out-of-scope follow-up. Verifier matrix (local, Mac): * cargo update --precise 0.2.7 → removes 9 transitive 0.97 crates * single iroh / iroh-gossip / iroh-base version in Cargo.lock * cargo audit → 2 vulns / 4 warnings (unchanged, matches Day 11 baseline) * cargo clippy -p elastos-{namespace,identity,compute} -p localhost-provider --all-targets -- -D warnings → clean Mac cannot fully build elastos-server (pre-existing crosvm cross-OS gap unrelated to iroh), so the Linux CI run on this commit is the definitive gate. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 27, 2026
…sson PR #1 (chore/runtime-cve-hygiene → main) opened with red CI because the Step 2 verifier matrix used local `cargo test` only; the Linux CI gate runs `cargo fmt --check`, `cargo clippy -- -D warnings`, and `cargo build --release` on top. Four classes of issue surfaced and were all fixed on the CVE branch (HEAD now d32cc3a, mergeStateStatus CLEAN): * fmt drift (5 sites, Day 7 + Day 10 leftovers) * 6 generic-array 0.14.9 deprecation cascade (sha2 + aes_gcm) * 1 clippy::type_complexity (4-tuple return in WasmProvider) * 5 E0308/E0599 from two coexisting iroh versions (distributed-topic-tracker 0.2.8 silently bumped iroh dep to 0.97) Updated the team-facing row + one-line update + new appendix to reflect this. Includes an explicit "sign-off discipline lesson learned" note — the same gap killed Phase 10.6 in its first session, so the Step 2 verifier matrix will be amended to run the full CI gate locally before any future "ready for review" claim. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
CI is now green ✅ — HEAD The PR opened with red CI because the original Step 2 verifier matrix used local
Audit posture unchanged from Day 11 baseline: 2 vulns (both deferred hickory-proto CVEs, documented in Sign-off discipline note: the Step 2 verifier matrix is being amended to run the full Linux CI gate ( Ready for reviewer eyes whenever you have time. The |
SashaMIT
added a commit
that referenced
this pull request
May 28, 2026
After Anders shipped v0.3.0 (Browser/Wallet/passkey-first Home/typed
providers, 12 commits, +119k LOC, 14 new crates), wrote a 1-page
integration-readiness memo for the v0.3.1 review window. All claims
verified against source, not paraphrased from the release blurb.
Key findings (each backed by a reproducible command in §3, §4, §5):
* v0.3.0 ships excellent architecture docs (PRINCIPLES, ROADMAP,
state.md, per-feature). Documentation quality is high; security
discipline (fail-closed, no-fallback, "what is proven" vs
"what works") matches our own Phase 10 hardening philosophy.
* v0.3.0 main does not build on macOS: elastos-crosvm hits BSD/Mac
libc gaps that no cfg-gate covers. The elastos-server crate has
an unconditional path-dep on crosvm, so the whole server does
not compile. Pre-existing condition inherited from v0.2.0.
* Anders explicitly knows this: scripts/check-wci-alignment.sh
has 'public installer must stay Linux-only until update/install
support macOS coherently' as a hard alignment gate.
* sash/local-test closes both halves of that gap (crosvm Mac stub
+ elastos-vz native substrate). Even if Anders does not adopt
the VZ substrate as a product feature, the cross-compile work is
the mechanical prerequisite for satisfying his own darwin gate.
* Cargo audit on v0.3.0 worktree: 35 vulns / 12 warnings. Our CVE
branch (PR #1) closes ~20 of those mechanically (wasmtime 17->36
cascade, rustls-webpki, rustls-pemfile removal, lru, cap-primitives).
* Four NEW vuln classes appeared in v0.3.0 from new deps:
aws-lc-sys 0.37.0 (5 CVEs), bytes 1.11.0, quinn-proto 0.11.13,
and rsa 0.9.10 (RUSTSEC-2023-0071 — Marvin timing attack, the
standard 'do not use rsa for any secret-bearing operation'
advisory). Worth flagging independent of branch sequencing.
* Rebase shape mapped per-file. Two real conflict hotspots:
carrier_bridge.rs (v0.3.0 +1002 / ours +917 in different
directions — 1000-line file rewrite from both sides) and
supervisor.rs (v0.3.0 +148 / ours +3800 — replay-on-top is
feasible). Estimate 2-3 days of careful work for Mac VZ
rebase, ~half-day for CVE-branch rebase.
No code changes outside this memo. Both feature branches remain
stable, CI-green, awaiting Anders' v0.3.1 review window.
Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 28, 2026
Three-paragraph message for the operator to send (or edit and send) to Anders ahead of his v0.3.1 review window. Acknowledges v0.3.0's architecture quality genuinely, surfaces the three useful signals from our side (PR #1 closes ~20 of v0.3.0's 35 CVEs, Mac VZ rebase needs his decision on macOS scope, rsa 0.9.10 Marvin finding is independent), points to V030_INTEGRATION_NOTES.md for evidence, asks for nothing. Kept short on purpose. He just shipped a large release and is heads-down reviewing 0.3.0 publish. This is a heads-up artifact, not a request. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 28, 2026
…ulns)
Closes 18 vulnerabilities in one bump: the entire wasmtime cluster
(RUSTSEC-2026-0020/-0021/-0085/-0086/-0087/-0088/-0089/-0091/-0092/-0093
/-0094/-0095/-0096/-0149, -2025-0046/-0118, -2024-0438) plus the
cap-primitives transitive (RUSTSEC-2024-0445).
Cumulative result on Linux build target:
cargo audit on v0.3.0 baseline: 35 vulnerabilities / 12 warnings
cargo audit after Day 1: 21 vulnerabilities / 7 warnings
cargo audit after Day 2: 3 vulnerabilities / 5 warnings
Day 2 delta: -18 vulnerabilities / -2 warnings
The 3 remaining vulnerabilities are out of scope for this branch:
- 2 hickory-proto CVEs (RUSTSEC-2026-0118/-0119) — DEFERRED, require
hickory 0.26 which is still pre-release. Same disposition as the
v0.2.0 CVE branch and documented there.
- 1 rsa Marvin attack (RUSTSEC-2023-0071) — NEW in v0.3.0 via
elastos-auth / wallet-provider. Flagged to Anders in
V030_MESSAGE_DRAFT.md for project-level decision before patching.
==== What changed ====
elastos-compute/Cargo.toml
wasmtime 17 → 36 (current stable line)
wasmtime-wasi 17 → 36
wasi-common: REMOVED (no longer pulled in directly; preview1 host
functions now come from wasmtime_wasi::preview1)
Inline comment block documents the migration rationale and the new
FIFO carrier transport.
elastos-compute/src/providers/wasm.rs (port of archive/runtime-cve-hygiene-v020-base + v0.3.0 principal binding)
WASI API migration:
wasi_common::pipe::{ReadPipe, WritePipe} → REMOVED
wasmtime_wasi::sync::WasiCtxBuilder → wasmtime_wasi::WasiCtxBuilder
wasmtime_wasi::WasiCtx → wasmtime_wasi::preview1::WasiP1Ctx
+ use wasmtime_wasi::{DirPerms, FilePerms}
+ use wasmtime_wasi::preview1::{self, WasiP1Ctx}
Carrier bridge transport rewrite:
OLD: fd-injection via WasiCtx::insert_file (FD 3/4)
REMOVED upstream in wasmtime-wasi 24+ — no workaround
NEW: per-launch carrier dir + two FIFOs (request, response) under
/tmp/elastos-carrier/<capsule-id>/, preopened into the WASI
sandbox at /_carrier via DirPerms::READ + FilePerms::READ|WRITE.
New helpers: carrier_dir_for(), setup_carrier_fifos(),
cleanup_carrier_dir(), mkfifo(), CARRIER_GUEST_DIR constant,
BridgeTransport enum (currently single variant Fifos), Drop
impl on RunningInstance to GC the carrier dir.
Type-complexity fix preserved from PR #1 commit 46e3edd:
WasiContextWithBridge type alias for build_wasi_context return.
Stricter entrypoint policy (v0.3.0 change ported on top):
Missing _start now returns an ElastosError::Compute instead of
silently falling back to main() or emitting a warning.
v0.3.0's principal-binding work, layered back on top of the archive port:
+ BridgePipes.capsule_id: String
+ BridgePipes.principal_id: Option<String>
+ WasmProvider.bridge_principals (Arc<RwLock<HashMap<...>>>)
+ WasmProvider::set_bridge_principal() / clear_bridge_principal()
+ build_wasi_context() now takes principal_id: Option<&str> and
threads it through setup_carrier_fifos() into the returned pipes.
+ Both test manifests get authority: None (v0.3.0 added the field).
Tests included (all from the archive branch's coverage):
test_default_bridge_transport_is_fifos
test_setup_carrier_fifos_creates_dir_and_fifos_with_correct_modes
test_cleanup_carrier_dir_is_idempotent
test_setup_carrier_fifos_round_trip_via_host_ends
test_mkfifo_returns_typed_error_on_invalid_path
test_running_instance_drop_cleans_carrier_dir
==== Reconciliation notes ====
The v0.3.0 main delta on wasm.rs (+27/-12) was small and focused on
principal binding. The CVE branch delta (+500/-113) was the wasmtime
migration plus FIFO transport. They touched mostly disjoint regions, so
the port was a copy-archive-then-overlay-v0.3.0 operation:
1. Copy elastos-compute/src/providers/wasm.rs from
archive/runtime-cve-hygiene-v020-base (the known-working post-CVE
end-state).
2. Add v0.3.0's two new fields to BridgePipes.
3. Add v0.3.0's bridge_principals field + setter/clearer to WasmProvider.
4. Thread principal_id through setup_carrier_fifos and build_wasi_context.
5. Apply v0.3.0's stricter _start policy and the TODO-comment cleanup.
6. Add authority: None to both test manifests.
Carrier_bridge.rs was NOT touched on Day 2. Its only API contact with
wasm.rs is BridgePipes { capsule_stdout, capsule_stdin } — neither of
which moved. The two new BridgePipes fields (capsule_id, principal_id)
are passive additions that consumers can read but aren't required to.
Day 3 will handle any carrier_bridge.rs reconciliation needed for the
axum-server 0.7 → 0.8 / rustls-pemfile migration.
==== Verification ====
cargo check -p elastos-compute (Mac): green
cargo check --workspace --exclude crosvm/server/runtime (Mac): green
cargo clippy --workspace --exclude crosvm/server/runtime/guest
--all-targets -- -D warnings (Mac): green
cargo fmt --all --check: clean
Linux CI on PR #2: pushed for verification
The elastos-crosvm / elastos-guest Mac compile failures are pre-existing
in v0.3.0 (sockaddr_in.sin_len, ioctl signature, openpty winsize
pointer) and reproduce on plain origin/main. Not caused by Day 2.
Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
May 28, 2026
…eview
Top-level reviewer's doc covering:
- Headline result (35→3 vulns / 12→4 warnings, 91% / 67% reductions)
- Why this PR exists (v0.3.0 rebase rationale; CVE work isolated
from the open Mac VZ product question)
- Full 4-day timeline with per-day commit + Δ metrics, linked to
the existing DAY_1.md / DAY_2.md / DAY_3.md notes
- CVE closure ledger by RUSTSEC ID — closed (32) and accepted (3+4)
- Cargo.toml + Rust source change summary
- Reviewer's checklist (read-in-order guide)
- Final verification record (audit / fmt / clippy / test / CI history)
- Handoff section with the three project-level decisions Anders
might want to weigh in on (rsa disposition, bincode migration
scheduling, Mac VZ direction)
No code changes today — Day 4 is the ship-it day. The next steps
(flip PR #2 from Draft → Ready, close PR #1 with explanatory comment)
are handled outside the commit history via gh CLI.
Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
Closing in favour of #2, which rebases this work onto v0.3.0 main per Anders' v0.3.1 review schedule. Same scope, same audit ledger, same security disposition; the v0.3.0 base makes the diff more useful for review against current main. Closing rather than merging-and-rebasing to keep one canonical PR open. The original v0.2.0-based branch is preserved as the tag #2 includes:
Thanks for the v0.3.0 release timing — having a fresh main to rebase onto made the audit ledger genuinely cleaner. |
SashaMIT
added a commit
that referenced
this pull request
Jun 17, 2026
…ent audit, action enforcement, hardening pass Closes the four highest pre-audit findings as fail-closed boundaries, each with a regression test. #1 CEK reconstruction integrity (HIGH): bind the reconstructed CEK to a published commitment before use and add 3-share cheater-detection on the live quorum/threshold open path. A Byzantine node returning a well-formed but wrong-valued share now FAILS THE OPEN CLOSED; an uncommitted 2-of-2 open is refused rather than yielding a silently-wrong key. (ddrm-envelope, decrypt/encrypt/key providers, media-authority/producer rails) #2 Tamper-evident audit + content-open custody (GAP-8): hash-chained (seq + prev_hash + record_hash), ed25519-signed records with a crypto- agility tag, persisted 0600 signing key, verify_chain, emit() -> Result. A content-open event is emitted on the viewer open path; a failed audit append fails the open closed (503). ed25519 lives in the trusted core (no capsule ML-DSA dependency). Caveat in-code: tamper-evident against external editing + non-repudiable, NOT against a live-compromised runtime (external anchoring is a deliberate follow-on). (elastos-runtime primitives/audit.rs, elastos-server viewer_open/gateway) #3 Central action-enforcement: validate every provider dispatch against the operation's required action via required_action_for(op), not the token's self-declared action. Enforced centrally at the trust boundary (bridge + HTTP provider proxy); fail-closed Admin default for unmapped ops. (provider_resource.rs, carrier_bridge.rs, handlers/provider.rs) #4 Quick hardening: (a) DKMS_AUTHORITY_NODE_SET_ID_B64 mandatory in release — absent it, the node refuses to authorize against a caller-declared node-set (cross-quorum replay defense); fallback only in test/dev-modes. (b) MAX_LINE_BYTES (16 MiB) cap in vsock-proxy: all line reads routed through a bounded reader so a newline-less peer can't OOM the bridge. (c) gf256_mul made branchless (arithmetic masks, no tables, fixed 8 iters) to remove the secret-dependent control-flow timing channel. (d) effective_now clamped to the node clock at issuance so a caller can only shorten its session window, never extend it past its TTL. Also: widen check-wci-alignment.sh to exempt manifest-less crates (crypto libraries / node binaries are not deployable app capsules) and dependency files; HANDOVER Day 139 checkpoint; incidental cargo-fmt normalization to keep the workspace fmt-clean. Verified per-crate: ddrm-envelope 40/40, dkms-authority 24/24, vsock-proxy 3/3; alignment-check green. (These crates are outside the elastos workspace, so `just verify` does not exercise them.) Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
Jun 17, 2026
Close the last pre-audit backlog item — reduce observable metadata and document the trust model honestly for the external audit. - viewer_open: log subject/content_id only as non-reversible truncated SHA-256 fingerprints (log_fp); no raw (wallet, content_id) at info!. - ddrm-envelope: channel_pad module — coarse power-of-two size bucketing (ISO 7816-4, fail-closed unpad, cap-safe) applied plaintext-side before sealing at every dKMS channel seal/open site (dkms-authority, key-provider, ddrm-runtime-open, dkms-live-recover) to blunt on-path length analysis. - docs/THREAT_MODEL.md: states the 2-of-3 (NOT "no collusion") trust model, the observable (wallet, content_id, time) access pattern, the audit non-repudiation caveat, and what we do NOT defend (oblivious lookup is the flagged next scope). - HANDOVER: Day 139 closure addendum — pre-audit backlog #1-#5 closed. PRE_AUDIT.md intentionally left untracked (found-and-fixed exploit detail; public repo) — hand to the auditor out-of-band. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
added a commit
that referenced
this pull request
Jun 17, 2026
…lockfiles - PRE_AUDIT.md: firm-facing scoping evidence (findings + verified-clean list) for the pre-audit security backlog #1-#5 (now closed). - CONFIDENTIAL_COMPUTE.md: TEE opportunity audit + quorum hardware reality. - README + capsule lockfiles refreshed. Co-authored-by: Cursor <cursoragent@cursor.com>
SashaMIT
pushed a commit
that referenced
this pull request
Jun 17, 2026
…re doc Addresses a Carrier/Principles alignment review (#4, #9, #7, #12, #10). - UI bridge rewritten as a Carrier-shaped host adapter: one inspectInvoke(operation, payload) targeting the runtime's node-local control API (POST /api/provider/inspect/<op> + x-elastos-home-token), exactly as the library/browser capsules call providers. HTTP is the transport adapter BELOW the capsule contract (CARRIER.md "Where HTTP Fits" #1), not something the capsule "knows"; swapping transport needs no UI change. Degrades to sample data when no token/bridge is present. - docs: new "Transports & Carrier alignment" section recording the two transports (capsule carrier_invoke path — implemented/tested; browser control-API path — not yet wired) feeding ONE authority decision (crate::inspect), and the honest finding that the gateway dispatches via ProviderRegistry::send_raw with GatewayState holding only the registry — so the browser path needs inspect exposed as a registry provider, which also converges on one canonical path (#10) and lets handle_inspect retire. No runtime behaviour change; capsule/carrier path unchanged (278 lib tests still green). UI passes node --check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016ZKy5Cca9RzwDuLb1szdeq
SashaMIT
pushed a commit
that referenced
this pull request
Jun 17, 2026
Both remaining enrichments. Sub-provider coverage (#1): - ProviderRegistry::sub_provider_schemes() (elastos-runtime, additive) lists the elastos:// sub-provider schemes (did/key/peer/…) that schemes() omits. - RegistryInspectSource lists main + sub schemes; CatalogInspectSource's running-status detection now matches sub-provider-backed schemes too. Live per-capsule audit (#2): - AuditSource trait + AuthAuditSource: reads the signed runtime audit log (RuntimeAuditEventV1 in auth state), correlates by capsule_id (capsule name), and fills the detail view's audit section — recent events (newest-first, capped) + total/denied counts. Runs on a blocking task off the async workers. - InspectProvider gains an optional audit source (with_audit builder); project renders the live audit. Records expose only safe fields (ts/event/reason/ success) — no signatures or handles (#16). - serve_cmd wires AuthAuditSource(data_dir) on both serve paths. Honest remaining: granted_capabilities stays empty — bearer-token caps have no central registry and RuntimeAuditEventV1 has no resource/action, so observed grants need a capability-event source that records them. Verified: cargo test -p elastos-server inspect_provider — 10 passed (incl. live audit + sub-provider tests, #16 no-leak preserved); cargo test -p elastos-runtime --lib — 278 passed (additive registry method, no regression). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016ZKy5Cca9RzwDuLb1szdeq
SashaMIT
pushed a commit
that referenced
this pull request
Jun 20, 2026
…partial Re-verified all eight PRE_AUDIT findings against the current tree (deep + passing tests for #1/#3/#6; code + mechanism for #2/#4/#5/#7/#8). Adds a dated verification banner with file:line evidence and flips the #1/#2 status cells. - #1 (was HIGH/CRITICAL) RESOLVED: CEK reconstruction is integrity-checked end-to-end and production-wired — producer publishes cek_commitment at mint, the open path reconstructs via reconstruct_quorum_cek_checked (3+ shares cross-check / commitment binding / degraded 2-share-without-commitment refused). Byzantine-share tests pass (decrypt-provider 146/0). - #2 PARTIAL by design: log-redaction is done (log_fp fingerprints the wallet/content triple); blinded identifiers / oblivious lookup / frame padding / node-operator visibility remain documented roadmap, not code defects. Kept for the firm. - #3 RESOLVED (audit tamper-evidence; recorded earlier this branch). - #4 RESOLVED: central required_action_for map, fail-closed on unmapped ops, enforced at the bridge on the required (not token's) action. - #5 RESOLVED: node-set-id pin mandatory in release (compile_error fence + authorize refuses a caller-declared node-set). - #6 RESOLVED: vsock-proxy MAX_LINE_BYTES cap fails closed; binds the guest vsock wildcard CID, not TCP 0.0.0.0. - #7 RESOLVED: GF(256) multiply rewritten branchless (mask selects, fixed 8 iters). - #8 RESOLVED: effective_now clamps the caller clock in release (window can only shrink). No code change. Purpose: hand the external firm a trustworthy "scope these OUT" list. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VjFQt6DK9ZGnLs4ykUWsuX
SashaMIT
added a commit
that referenced
this pull request
Jun 22, 2026
…ode + bank the tool Empirical check (verify-selectors.mjs): AuthorityGateway 0x09dBe7 is an EIP-1967 proxy -> impl 0x305e3726...; ALL 8 core selectors present in deployed bytecode (buyAccess native+erc20, hasAccessByContentId, sellAccess, withdrawListing, paymentProcessor, sellersOf, listings). Resolves the red-team's #1 'keccak!=ABI' caveat for the whole buy/list/cancel/has-access/payment surface; list+cancel are on the SAME gateway. CONTRACTS.md verification status updated; re-run the tool after any proxy upgrade. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SashaMIT
added a commit
that referenced
this pull request
Jun 23, 2026
… shell honest about BUILT vs PENDING Council Systems-Architect #1 finding + Frontend-Backend + deep-audit LOW. The storefront shell declared routes (get/order.assemble/order.cancel/acquire/vault/listed/history) that the gateway does NOT serve (search/sections/order.{sell,withdraw,approve}/buy), so every non-discovery call 404-fell-back to MOCK and the divergence hid behind the fallback ("browser-verified != wired"), plus a Listing schema gap. - NEW docs/marketplace/API_CONTRACT.md: the single canonical /api/market/* vocabulary both sides converge on — each route marked BUILT (served today) or PENDING (Phase 2/3), the name-fork reconciliation (order/assemble->buy, order/cancel->order/withdraw, +order/sell/approve for resale), the auth posture, and the Listing schema gap (no name/medium/listings[] until Phase-2 KID enrichment). - api.js: header now references the SSOT and accurately marks BUILT vs PENDING (PENDING routes are mock-only, never set live=true); renamed the cancel call to the BUILT /order/withdraw and the buy call to the BUILT /buy, with Phase-2 body-mapping notes. - app.js: cardHTML tolerates the lean live Listing schema (guards l.listings.reduce) so real gateway data cannot crash the Discover grid — the Design Director's "crash invisible in mock review". Full live-wiring (build /get + /vault, send the Home token, enrich the schema) is Phase 2. shell syntax OK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SashaMIT
added a commit
that referenced
this pull request
Jun 23, 2026
…e/cover/content_cid/mime) Building the enrichment slice that is genuinely buildable+verifiable here (only the network fetch is live), correcting the earlier over-conservative "all live" framing. - market_reads.rs: PURE extract_cid (content-market's exact ipfs:// / /ipfs/ / Qm-bafy rule) + parse_asset_metadata (the same field paths content-market enrich_listing reads: name, description, image|media.previewURL, media.uri->content_cid, media.contentType->mime). 2 unit tests (extract_cid PC2 rules; parse paths + poster fallback + empty->None). This is the descriptive slice; the full kid==contentId validation is the hardening follow-on (PHASE2_ENRICHMENT.md). - market_get: optional &token_uri -> enrich_from_token_uri fetches the metadata.json via the content/* plane (P4) + parses + merges as `metadata` into the response. Best-effort (live terms are load-bearing). The fetch is compile-verified; Cursor live-verifies it resolves real assets. - Shell: get() passes token_uri + merges the enriched name/cover/content_cid/medium onto the cached listing (so acquire() now has a real content_cid on the live path); mimeToMedium maps mime->medium. Browser-verified the detail view still renders on the mock path (no regression, no console errors). market_reads 4/4 pass; crate compiles; shell syntax OK. This unblocks live display + the real buy->pin (content_cid) — checklist items #1 (descriptive), #2-prep, #6. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SashaMIT
added a commit
that referenced
this pull request
Jun 23, 2026
…anchors/buttons (audit #1) The UI/UX deep audit's #1 finding (a11y scored 38%): the storefront was keyboard-INOPERABLE — cards and nav were div/span+click, so the well-built :focus-visible ring reached nothing and the app was un-buyable without a mouse. Fixed by giving everything real semantics (the hash router already drives off href, so nav is native): - Cards: <div data-id + JS click-delegation> -> <a href="#/asset/${id}"> with a concise aria-label (name, creator, medium, price); the decorative thumb (poster/glyph/lock) is aria-hidden so the label stays clean. Removed the now-redundant card click delegation. - Rail nav + the Vault pill -> real <a href> (native nav); router() now also toggles aria-current="page" on the active route; removed the redundant rail click handler. - Back link -> <a href="#/discover"> (both the skeleton and the loaded view); removed its click handlers. - Clear-filters -> <button> (+ a button-reset on .shelf .more so it matches the prior span styling). Verified via computed styles + DOM (screenshot tool was returning blank frames despite the page rendering): card is <a> href=#/asset/… aria-label set, keyboard-focusable, :focus-visible ring shows; rail aria-current =page; all elements visibility:visible/opacity:1, correctly sized; no console errors. Modal a11y (role=dialog/ Esc/focus-trap) + the async money-path states land in the next sub-pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SashaMIT
pushed a commit
that referenced
this pull request
Jul 3, 2026
…cture/UX verdict, vision, ordered roadmap Capstone of the 0.01% assessment (professionals + innovator + visionary + advisor + stakeholder lenses): overall grade 6.5/10 (8 on the security/crypto core, 5 on the UX + unbuilt ends), the architecture verdict (right primitives, trusted-core inversion is the #1 structural debt — sequence the restructure AFTER the wedge except halo-wiring), the UX verdict (one finished room, three design systems, a Web3-leaking money path), the Sealed-Rights Commerce vision + wedge, and one leverage-ordered master plan converging on: close one receipt-backed sale, then ship the Tier-3 demo. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnpmuD7RtQ3NuTfRQJGrQb
SashaMIT
pushed a commit
that referenced
this pull request
Jul 4, 2026
…ent, casing desync, honest CLI Review pass on the mandate lifecycle (guardian: PASS w/ advisories; red-team: two real breaks + latent gaps). All folded: - DURABLE ENFORCEMENT (red-team #1): production built its CapabilityStore in-memory, so individually-revoked (unexpired) tokens would validate again after a restart — a revoke durably ATTESTED but not durably ENFORCED. The server now builds the store with_persistence (revocations + epoch survive restart) and fails closed at boot if persistence is unavailable. - ID-CASING DESYNC (red-team #2): hex::decode accepts UPPERCASE but the standing-envelope registry is keyed by the token's lowercase Display form, so an uppercase id revoked the token yet left the envelope (the dispatch path's only check) live. The handler now kills the envelope by the canonicalized id. Regression test: revoke_with_uppercase_id_still_kills_the_standing_envelope. - HONEST CLI (guardian F2/F4): the revoke headline now states exactly what is attested; revoked:false becomes an unmissable stderr WARNING (a mistyped id attests a revoke for a token that never existed while the real mandate stays live). The receipt command no longer inlines the receipt's own embedded signer into the suggested verify command (pinning a document's self-carried key is circular); it prints it as informational and tells the operator to pin the key they trust out-of-band. - TRACKED LATENT GAPS (guardian F1/F3, red-team #3/#4): recorded as G-M1..3 in docs/KNOWN_GAPS.md — the intent-channel dispatcher (zero non-test call sites today) must consult token revocation + epoch when wired, and its acts must reach the per-mandate receipt; same-uid control-plane trust boundary documented. Lifecycle test comment now states honestly which act path it models. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnpmuD7RtQ3NuTfRQJGrQb
SashaMIT
pushed a commit
that referenced
this pull request
Jul 4, 2026
…makes "performed" literal Sprint 7 registers the first genuine executor behind mandate dispatch, so "performed" stops being a documented empty-registry placeholder and becomes a real, side-effect-free operation the runtime actually does. runtime.audit_verify re-verifies the runtime's own tamper-evident audit chain (hash links + ed25519 signatures) — a pure read — and PERFORMS iff it truly verifies, DECLINES (=> Undelivered) otherwise. The outcome tracks real chain state, not the declaration: a corrupt or unsigned chain is honestly authorized_not_performed. Proven end to end through the PRODUCTION executor (no test stand-in): a read mandate + agent-key-bound signed intent => outcome "performed", receipt CapabilityUse success=true, authenticates. Folded in from guardian (CHANGES-REQUIRED) + red-team (SHIP + one fix): - Report what was TRULY done, not the declaration (guardian #1, P12/P16): the executor now reports resource = elastos://runtime/audit-chain (the whole chain it really reads, NOT the declared resource), action = read, and input_hash = empty (no arguments). So a mandate mis-scoped to another resource reconciles Diverged, never a misleading Matched (audit_verify_under_a_misscoped_mandate_diverges). - Require a signing key (red-team #1, P12): verify_chain(None) is a hash-only walk over a public algorithm, so an unsigned/memory-only log now DECLINES rather than over-claim a signature-verified read. A "performed" provably means signature-verified. - Fixed the now-stale "production executor set is empty" claims in the dispatch doc and KNOWN_GAPS G-M6 heading. - Documented residuals: verify_chain is O(chain) per call (DoS-bounded by the shell-only + agent-key-bound + replay-guarded mandate); the verified count is observed but not surfaced; a torn concurrent log line yields a fail-closed spurious Decline. Gate: clippy clean on changed files; elastos-server 1125 tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnpmuD7RtQ3NuTfRQJGrQb
SashaMIT
pushed a commit
that referenced
this pull request
Jul 4, 2026
…-dependent read Adds a second wired affordance whose outcome tracks REAL variable state, not just chain integrity: `runtime.content_seen` answers "did the mandate's own capsule successfully open content id X?" — so the SAME agent + method + declaration reconciles "performed" or "authorized_not_performed" depending on what the runtime actually recorded, proving the reconciliation is a genuine independent observation. Backed by AuditLog::principal_opened_content (sync, streams the durable log, early-returns). Handler + executor ratchets prove the state-dependence and principal isolation end to end. Folded in from guardian (CHANGES-REQUIRED) + red-team (DO-NOT-SHIP, conditional): - CROSS-PRINCIPAL ORACLE (red-team #5 / guardian #4, blocking): the first cut matched ANY principal's access, letting an agent learn whether anyone accessed an id. Now PRINCIPAL-SCOPED — matches only ContentOpen with the caller's own principal_id ("did I open it", not "did anyone"). ContentFetch is dropped (it carries no principal, so it can't be attributed). A ratchet proves a different capsule asking about the same id is Declined. - RECEIPT OVER-CLAIM (guardian #1, blocking): CapabilityUse carries resource + action but not the method, so a content_seen "read of X" was indistinguishable from a real content read. The mandate is now scoped to a content-access-CHECK resource (elastos://runtime/content-access/<id>), so the receipt honestly names a read of the CHECK, not the content bytes — mirroring Sprint 7's canonical-resource pattern. - WEAKER EVIDENTIARY BAR (guardian #2): the scan didn't verify signatures while audit_verify Declines unsigned logs for the same offline-rewrite threat. The executor now requires the log signed + verify_chain Ok before the scan, so a matched ContentOpen is signature-attested — the same bar as audit_verify. Gate: clippy clean on changed files; elastos-server 1128 + elastos-runtime 399 tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnpmuD7RtQ3NuTfRQJGrQb
SashaMIT
pushed a commit
that referenced
this pull request
Jul 5, 2026
… durable agent state (Sprint 17) An agent acting under a `write` mandate scoped to elastos://runtime/store/<key> now writes durable, readable-back, principal-scoped agent state — proving the council-hardened side-effecting pattern generalizes from a one-shot Inbox notification (Sprint 16) to real mutable data. New agent_store.rs: a durable KV store keyed by (capsule, key); last-write-wins with a monotonic per-key version; per-capsule key cap (256, evicting only that capsule's oldest, never another's, and NEVER the just-written key); atomic write; Err -> Declined. The full loop is proven end to end: grant -> write -> readback -> overwrite/ version -> revoke -> the same write denied with the value UNCHANGED -> the portable receipt carries both writes AND the denial, verified off-box. Honesty carried verbatim from the notify hardening (no free-text channel): the stored value is the declaration's input_hash COMMITMENT (the intent carries no payload bytes), not a smuggled payload; key + value + intent_id are all bounded to safe shapes BEFORE the write; principal-scoping is a (capsule, key) struct match (not a forgeable concatenated id), and capsule is gate-bound (check_intent_within_envelope denies WrongCapsule), so one agent can never read, overwrite, or evict another's key. Council review (guardian + red-team, fable). Both settled the #1 questions: no Performed-without-effect (the write lands before Ok; the cap provably cannot drop the just-written key even under same-second timestamps), and (capsule, key) isolation is airtight. Findings folded: - F1 (HIGH, both — the notify-F1 class): intent_id is PERSISTED, so it is now bounded to a slug like the key (pre-folded before the reviewers' diff snapshot) — closes a durable disk-fill via an unbounded field and pre-closes the phishing channel before any read surface lands. Ratchet: state_put_declines_an_unbounded_intent_id. - F2 (LOW, documented): whole-store O(total) rewrite per put — scale watch- item, bounded (operator-gated capsule count, every field length-capped); per-capsule sharding if it ever matters. - F3 (LOW, documented): "readable back" corrected — the function exists and is test-exercised; a production read route is a follow-up. Nothing on a trusted decision path reads the store, so self-writes cannot escalate. - fsync residual noted, consistent with the accepted notify baseline. Gate: clippy clean; 1156 server tests green (+9 state_put/agent_store ratchets incl. principal-scoping, cap-survives-own-eviction, field bounds, write-failure declines, and the end-to-end dispatch loop). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnpmuD7RtQ3NuTfRQJGrQb
4 of 6 tasks
Open
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR closes 32 of 34 baseline
cargo auditvulnerabilities (94%) and 2 of 6 baseline warnings without forking any upstream crate, introducing any new direct dependency, or breaking any wire contract.mainbaselinecargo auditvulnerabilitiescargo auditwarningsFull closure narrative:
docs/vz-backend/cve-hygiene/RUNTIME_CVE_HYGIENE_SIGNOFF.mdMerge sequencing & rollback plan:
docs/vz-backend/cve-hygiene/MERGE_PLAN.mdDay-by-day notes:
docs/vz-backend/cve-hygiene/DAY_1_NOTES.md…DAY_10_NOTES.mdFinal audit snapshot:
docs/vz-backend/cve-hygiene/final-audit-2026-05-27.jsonWhat was closed
cargo updatecascaderatatui,crossterm,rustls-pemfile); 207-line Cargo.lock reductionWhat was deferred (with named follow-up branches)
hickory-proto 0.25.2chore/runtime-cve-residuals-iroh-revbincode 1.3.3chore/bincode-2-migrationatomic-polyfill,fxhash,pasteEach residual is justified inline at `DAY_3_NOTES.md`, `DAY_9_NOTES.md`, `DAY_10_NOTES.md`.
Notable architectural change: FIFO carrier-bridge transport
The wasmtime 24+ migration required replacing the legacy FD-injection carrier bridge (where the host injected file descriptors 3 and 4 into the guest before `wasi.insert_file` invoked them) with a named-FIFO transport (where the host `mkfifo`s a request and response pipe and passes the directory path via `ELASTOS_CARRIER_FIFOS`).
Reviewer's checklist
Out of scope (not addressed here)
Test plan
Rollback safety
Each of the 12 commits is independently revertable (`git revert `); see `MERGE_PLAN.md` § "Rollback plan" for per-day revert mapping.
Made with Cursor