| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 7s
standards workspaces build + test / proof-rs (proof/conformance/v1/joulespec.toml, proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 1m1s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m25s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, -p sandbox-tee --features amd-kds,intel-pcs, sandbox-rs, linux) (pull_request) Successful in 1m37s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m46s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 3m21s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 7m1s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 12m16s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 1m15s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 7m28s
§13 prices the wait a run spends parked. It says nothing about the wait a run
spends *running*, which is usually the larger number. An interval that dispatches
an outward call and then sits until the result arrives holds its sandbox, and its
receipt charges the sitting as computation. A twenty-minute build, a review that
comes back the next morning, an approval that never comes — each is, in a
blocking runtime, an interval whose receipt is mostly waiting. Two runs doing
identical work bill hours apart, and the record reported both the same way.
So an executed segment may now carry a `CallAccount`: the calls it dispatched
and the results it resolved, each by call id.
A run is **non-blocking** when every executed interval accounts, and every
interval resolves only calls that were outstanding before it began. An interval
that resolves a call it dispatched itself did not hand off and return — it
waited, and the wait is inside its receipt. `RunRecord::wait_proof()` walks the
segments in order holding the outstanding set and returns one of:
- `NonBlocking` — no receipt in the run contains a wait for an outward call, so
the run's whole cost of waiting is the idle energy §13 already records, and
which §13.1 makes small for a transcript park. This is the condition under
which "waiting costs no computation" is a statement about the record rather
than about the runtime that produced it.
- `Blocked { segment }` — that interval consumed its own dispatch.
- `Malformed { segment }` — the account does not add up: a result answering a
call never dispatched, a call resolved twice, or one id dispatched twice. A
record that cannot be read is a different problem from a run that waited, and
is reported separately.
- `Unproved` — some interval did not account, or the run has no accounted
interval at all.
Two deliberate pieces of honesty
**An absent account is not an empty one.** Not accounting and accounting for no
calls are different statements, and they do not fold to the same bytes — a test
and a conformance check both hold that, so the marker is not merely a comment.
**A property of no intervals is not a property.** A run with nothing accounted
returns `Unproved`, not `NonBlocking`. Without that, every empty record would
certify the strongest claim in the section.
Backwards compatibility, checked rather than asserted
`calls` is `Option`, `serde(default, skip_serializing_if)`, and folded into the
chain only when present, so an interval recorded by `record_execution` hashes
exactly as it did before — pinned by a test against bytes written out by hand.
The committed vector confirms it: `durable.json` diffs as one added line and no
changed line, so `expect_runrecord_head` and `expect_transcript_head` are
unchanged, and the accounted trace gets its own address at
`b3:FINebhSRpv_1ncmpE3PaRG85MR8Ri1fDy4lmR1yI2DA`. That trace is the transcript
one with the account added and nothing else changed, so an implementation that
dropped the account would produce the transcript head where this one is
expected. Each id set is length-prefixed, so no id boundary is ambiguous.
Conformance class C15, and the pack's deliberate class count moves 14 → 15.
Evidence, on the build host: clippy `-D warnings` clean over the workspace, the
workspace's tests pass, and the full pack reports all 15 classes passed with no
skips. `cargo fmt` was not run: these workspaces are not rustfmt-clean.
Co-Authored-By: Claude Opus 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.