Security

[flyingrobots]

Migrated from Method backlog

This issue was created from a legacy filesystem backlog card. GitHub Issues are now the live work tracker; repository docs remain Method evidence.

Source backlog: docs/method/backlog/inbox/KERNEL_security.md
Original lane: inbox
Original legend: KERNEL

Original backlog card

Security

Milestone: Backlog | Priority: Unscheduled

Specifications and hardening for trust boundaries across FFI, WASM, and CLI surfaces. Includes commit signing specs, security context definitions, FFI validation, packet checksums, and provenance envelopes.

Issues: #20, #21, #38, #195, flyingrobots/continuum#74

T-10-2-1: Spec — Commit/Manifest Signing (#20)

User Story: As a deployment operator, I want a specification for signing commits and manifests so that I can verify the integrity and authorship of simulation artifacts.

Requirements:

• R1: Define what gets signed (commit hash, manifest digest, or both)
• R2: Specify signature format (detached Ed25519 or similar)
• R3: Define the canonical byte sequence that is signed (no ambiguity)
• R4: Specify how signatures are stored alongside artifacts
• R5: Address key rotation and revocation at the spec level

Acceptance Criteria:

• AC1: Spec document exists at docs/spec/SPEC-SIGNING.md
• AC2: Canonical signing input is defined unambiguously
• AC3: Spec covers key lifecycle (generation, rotation, revocation)
• AC4: Spec reviewed by at least one contributor

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Specification only. Covers commits and manifests.
Out of Scope: Implementation, CI integration, key management tooling.

Test Plan:

• Goldens: n/a (spec document)
• Failures: n/a
• Edges: n/a
• Fuzz/Stress: n/a

Blocked By: none
Blocking: T-10-3-1

Est. Hours: 4h
Expected Complexity: ~250 lines (markdown)

---

T-10-2-2: Spec — Security Contexts (#21)

User Story: As a runtime integrator, I want clearly defined security contexts for FFI, WASM, and CLI boundaries so that I understand what each boundary permits and denies.

Requirements:

• R1: Enumerate all trust boundaries in the Echo architecture (FFI, WASM, CLI, network)
• R2: For each boundary, define allowed operations and data flow direction
• R3: Define the threat model (what adversary capabilities are assumed)
• R4: Specify how sandboxing is enforced in WASM vs. native builds

Acceptance Criteria:

• AC1: Spec document exists at docs/spec/SPEC-SECURITY-CONTEXTS.md
• AC2: All four trust boundaries are enumerated with allowed operations
• AC3: Threat model section is explicit about assumptions
• AC4: Spec reviewed by at least one contributor

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Specification only. All runtime trust boundaries.
Out of Scope: Implementation of sandboxing, policy enforcement code.

Test Plan:

• Goldens: n/a (spec document)
• Failures: n/a
• Edges: n/a
• Fuzz/Stress: n/a

Blocked By: none
Blocking: T-10-2-3

Est. Hours: 4h
Expected Complexity: ~300 lines (markdown)

---

T-10-2-3: FFI Limits and Validation (#38)

User Story: As the Echo runtime, I want input validation at every FFI boundary so that malformed or malicious inputs cannot cause undefined behavior or panics.

Requirements:

• R1: Audit all existing FFI entry points and catalog their input types
• R2: Add length/range checks for all buffer and numeric inputs
• R3: Return typed errors (not panics) for all validation failures
• R4: Add #[deny(unsafe_op_in_unsafe_fn)] to all FFI modules
• R5: Document the validation contract for each entry point

Acceptance Criteria:

• AC1: Every FFI entry point has explicit input validation
• AC2: No FFI function panics on malformed input (returns error instead)
• AC3: At least one test per FFI function exercises the rejection path
• AC4: unsafe audit annotations are present

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: All FFI entry points in the echo crate.
Out of Scope: WASM boundary validation (separate task), network input validation.

Test Plan:

• Goldens: n/a
• Failures: Zero-length buffer, oversized buffer, null pointer, out-of-range enum discriminant
• Edges: Exactly-at-limit inputs, empty strings, max u64 values
• Fuzz/Stress: Property-based tests with proptest for buffer inputs

Blocked By: T-10-2-2
Blocking: none

Est. Hours: 6h
Expected Complexity: ~350 LoC

---

T-10-2-4: JS-ABI Packet Checksum v2 (#195)

User Story: As a JS-ABI consumer, I want packet checksums to use domain-separated hashing so that checksum collisions across different packet types are cryptographically impossible.

Requirements:

• R1: Define domain separation prefixes for each packet type (e.g., "echo.tick.v1", "echo.state.v1")
• R2: Replace existing checksum with SHA-256(domain_prefix || length || payload)
• R3: Maintain backward compatibility: accept both old and new checksums during a transition window
• R4: Emit a deprecation warning when an old-format checksum is received

Acceptance Criteria:

• AC1: All packet types have assigned domain prefixes
• AC2: New checksum computation uses domain-separated hashing
• AC3: Old checksums are accepted with a logged deprecation warning
• AC4: Round-trip test: JS → WASM → JS with new checksum format

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Checksum computation and validation for all JS-ABI packet types.
Out of Scope: Migrating to BLAKE3, removing old checksum support (future task).

Test Plan:

• Goldens: Bit-exact checksum values for known packets
• Failures: Truncated packet, wrong domain prefix, corrupted checksum
• Edges: Empty payload, maximum-size payload
• Fuzz/Stress: Fuzz packet payloads and verify checksum round-trip

Blocked By: none
Blocking: none

Est. Hours: 5h
Expected Complexity: ~250 LoC

---

T-10-2-5: Spec — Provenance Payload v1 (#202)

User Story: As an auditor, I want a canonical envelope format for artifact provenance so that I can trace the full lineage and verify signatures of any simulation artifact.

Requirements:

• R1: Define the Provenance Payload (PP) envelope structure (header, claims, signatures)
• R2: Specify the canonical serialization (deterministic JSON or CBOR)
• R3: Define claim types: built-by, derived-from, signed-by, reviewed-by
• R4: Specify how PPs chain (each PP can reference parent PPs by hash)
• R5: Align with in-toto or SLSA attestation formats where practical

Acceptance Criteria:

• AC1: Spec document exists at docs/spec/SPEC-0005-provenance-payload.md
• AC2: Envelope structure is fully defined with field-level documentation
• AC3: At least two worked examples (single artifact, chained artifacts)
• AC4: Relationship to SLSA levels is explicitly discussed

Definition of Done:

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: Specification only. Envelope format and claim vocabulary.
Out of Scope: Implementation, storage, query API, trust policy engine.

Test Plan:

• Goldens: n/a (spec document)
• Failures: n/a
• Edges: n/a
• Fuzz/Stress: n/a

Blocked By: none
Blocking: none

Est. Hours: 4h
Expected Complexity: ~350 lines (markdown)

[coderabbitai]

🔗 Related PRs

#178 - TT0 (#166) TimeStreams + wormholes spec lock [merged]
#209 - docs: math validation plan refresh + docs audit memo (#208) [merged]
#247 - M2.1: DPO concurrency litmus (spec + tests) [merged]
#326 - Echo contract hosting roadmap [merged]
#380 - feat(core): expose retained evidence posture on readings [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[alonro1github]

For context on Security: teams working on device compliance often outgrow single-vendor or TFTP-only workflows when they need compliance baselines, multi-vendor coverage, and tested restore paths. If it helps, I can share a few patterns that worked in similar migrations (happy to keep it technical and non-promotional).

[flyingrobots]

@alonro1github Thanks for the offer. This issue is fairly old and predates a lot of Echo's current architecture.

Several of the topics listed here, like signing, provenance envelopes, trust boundaries, checksums, etc. were captured before the current architecture settled around a split between compiler evidence, assurance evidence, and runtime evidence.

The current direction is closer to:

• Wesley produces deterministic compiler facts, schema/law hashes, contract bundle manifests, and bounded operation artifacts.
• Holmes (a Wesley sidecar) ingests and validates Wesley evidence such as law diffs, law coverage, capabilities reports, and contract bundle manifests.
• Echo owns runtime admission, deterministic execution, receipts, replay, and cryptographic witnesses for runtime outcomes.

I'm going to close this as obsolete and will consider replacing it with smaller issues that map to the architecture more accurately. Roughly:

Conventional Security

• WASM boundaries
• Sandboxing
• Release signing
• Build provenance

Wesley / Holmes Evidence

• Schema and law hashes
• Contract bundle manifests
• Evidence bundle validation
• Law coverage gates
• Capability reports
• Provenance for generated artifacts

Echo Runtime Witnessing

• Admission tickets
• Runtime receipts
• Outcome witnesses
• Reading envelopes
• Replay verification
• Deterministic attestation chains

If you've worked on provenance, attestations, evidence bundles, or independently verifiable execution records, I'd be interested to hear about patterns that held up well in practice. That is much closer to the current direction than device-compliance or restore-path workflows.