| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 48s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m41s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m10s
standards workspaces build + test / proof-rs (proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 2m18s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m38s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 2m43s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 5m23s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 13m57s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 4m28s
Sweep 2026-10-19 item #7, second half, by the owner's decision. Each checkpoint was decided alone: a unit could read data an attacker writes and later reach an endpoint it is granted, each call passing its own check, and nothing connected the read to the egress. The Enforcer is stateless by design (C2), so the connection had to be state the run carries explicitly. sandbox-capability (SPEC §5.8): - Grants.flow: FlowGrant { untrusted: [FlowSource { kind: Path|Kv|Program, pattern, origin }], tainted_may: [FlowSink { kind: Egress|Exec, target, accepts }] }. Omitted when empty, so a grant set without it keeps its bytes. - RunTaint: the origins of untrusted data a run has read; only grows. - Two pure Enforcer functions: taints(source), the origins a read adds; and may_reach(sink, &taint), where a tainted run reaches a sink only where tainted_may opens it to EVERY origin it carries (entries combine; `*` opens to any target or origin; an unopened sink is closed). Additional to the sink's capability, never instead. A decision stays a function of its inputs, the run's taint among them, as I/O counters already are. sandbox-exec-wasm (S2, where the live checkpoints are): HostState carries the taint. A storage or kv read that returns data, and a program's output, taint the run from a source the grant marks; egress and exec are refused with TAINTED (-6, distinct from DENIED) when the grant has not opened them to the run's origins. sandbox-exec-os is untouched: it refuses network and process grants outright, so no sink is reachable there. sandbox-runtime: grants_content_id binds flow_untrusted and flow_tainted_may when present, so the flow grant is part of the capability surface (SPEC §1.2); a grant without one keeps its id. Conformance class C13: sequence vectors (a run's calls in order; reads check the origins after, sinks whether reachable), in code and in the new conformance/v1/flow.json. The pack count goes to 13. SPEC §5.8, spec/capabilities.md (the enforcer contract: pure, with the run's history as an input), spec/conformance.md, conformance/v1/README.md; SPEC §10's class list was missing C11 and C12 and now lists C11–C13. Residuals, stated in §5.8: an unmarked source is read as the principal's data, and a tainted run's writes are not marked, so data can lose its taint between runs. Note: running gen_vectors also rewrites attestation.json and negative.json with "mechanism": null, a drift that predates this change; left out of it. Tests: - capability: three unit tests (a read carries every matching source's origin, kinds do not cross, `*` is any program; a tainted run reaches only what is opened to all it carries, entries combine; the taint only grows and an empty flow grant is not encoded). - exec-wasm: three end-to-end through real guests (an untrusted storage, kv or program read closes the egress that follows, a clean read leaves it open; an untrusted read closes the launch that follows; a sink opens only to the origins named, and no flow grant is untouched). - runtime: the flow grant is bound into the grant id, every part of it. - C13. Mutation testing: 17 mutants; 16 killed, 1 equivalent (the clean-run early return in may_reach: an empty taint already satisfies "every origin"). Verified on the build host: sandbox-rs 428 tests (--locked); every conformance class passes, C13 in code and from flow.json; clippy -D warnings clean on sandbox-capability, -exec-wasm, -runtime, -conformance. Repo checks pass. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| v1 | ||
| README.md | ||
| VERSIONS.md | ||
Sandbox conformance vectors
Signed, content-addressed wire vectors for the Sandbox standard (SPEC §10, ../spec/conformance.md). An implementation is conformant for the tiers it advertises if it round-trips these vectors with no skips.
The vectors are the authority. They are not illustrative: each is a real, cryptographically computed value, and the reference harness recomputes every content address, sealed JCR-1 envelope, and Ed25519/JCS signature and checks it against the committed file. A change to wire behaviour MUST regenerate the vectors and note it in VERSIONS.md.
Layout
conformance/
├── README.md — this file
├── VERSIONS.md — vector-set changelog
└── v1/ — the v1 vector set
├── content_addressing.json — C1: bytes → BLAKE3 content id
├── capability.json — C2: grant set → allow/deny decisions (incl. negatives)
├── receipt.json — C3: per-device receipt → core, content id, sealed JCR-1 envelope
├── attestation.json — C4: attestation → JCS bytes, content id, Ed25519 signature
├── tier.json — C5: grant set + flags → required tier
├── negative.json — C-neg: malformed receipts + attestations a host MUST reject
└── confidential.json — C-tee: SEV-SNP report verification + audit-chain vectors
Vector classes
-
C1 — canonicality. Content addressing (
b3:+ base64url over BLAKE3-256) is byte-stable. -
C2 — capability enforcement. The deny-by-default
Enforcerreturns the fixed decision for each query, including the negatives (ungranted device class, read-only path written, wrong port). -
C3 — receipt integrity. The per-device records sum to the total; the
(provenance, measured_uj)coupling holds; the sealed JCR-1 envelope verifies under the committed steward key and matches the canonical core. -
C4 — attestation. The core canonicalizes to the fixed JCS bytes and verifies under the committed supervisor key; the device classes match the receipt's.
-
C5 — tier minimization. Each grant set + flag combination resolves to the lowest satisfying tier (S0–S7).
-
C-neg — adversarial negatives.
negative.jsonholds malformed artifacts a conformant host MUST reject: aHwShuntreading with no measured figure, anEstimatorcarrying one, a total that does not equal the device sum, a measured-coverage mismatch, an attestation that omits an accelerator the receipt metered (SPEC §7.2), an S6 attestation without TEE evidence (SPEC §7.6), a replay journal that diverges and one that is truncated (SPEC §8), and a mid-run grant-set mutation whose content address changes (SPEC §1.2). The harness asserts each is rejected or detectable. -
C-tee — confidential + sovereign.
confidential.jsoncarries SEV-SNP report vectors — a valid report that verifies against policy + VCEK, plus negatives (wrong launch measurement, tampered body that fails the ECDSA-P384 signature) — and a hash-chained audit-log vector that must verify (SPEC §7.6, §7.7).
Negatives are what a standard certifies; growing this set (tier-minimization violations, anti-evasion probing) is the highest-value contribution here — see ../CONTRIBUTING.md.
Regenerating and verifying
cd ../sandbox-rs
cargo run -p sandbox-conformance --bin gen_vectors # rewrite conformance/v1/*.json
cargo test -p sandbox-conformance # verify in-code + file-backed
cargo run -p sandbox-cli -- conformance # human-readable pass/fail
Ed25519 signing is deterministic (RFC 8032), so the signatures are reproducible known answers: regenerating on an unchanged reference produces byte-identical files.