[irzhywau]

Note

This is part of a stacked PR chain — review only the commits of this checkpoint; earlier work is in the PRs below it in the stack.

Stack (top → bottom)

• feat(protected-content): runtime lifecycle — mint, buy, play, purchase closeout #36 feat/protected-content-runtime-lifecycle
• feat(protected-content): chain rights evidence and typed decisions #35 feat/protected-content-rights
• feat(protected-content): Runtime release authority and persisted state #34 feat/protected-content-runtime
• feat(protected-content): sign rights requests with Wallet #33 feat/protected-content-wallet-rights
• feat(protected-content): custody provider protocol and process #32 feat/protected-content-custody-provider
• feat(protected-content): bridge authenticated release reconstruction #31 feat/protected-content-key-reconstruction
• ➡️ feat(protected-content): threshold custody envelopes and key reconstruction #30 feat/protected-content-custody (this PR)
• feat(protected-content): canonical content identities, rights grants, release contracts #29 feat/protected-content-contracts
• feat(collaboration): Profile/Chat product UI and Home window chrome #28 review/collaboration-product-integration
• feat(collaboration): signed network protocol, Carrier transport, Profile authority #27 review/collaboration-foundation
• main

Base: feat/protected-content-contracts ← Head: feat/protected-content-custody (checkpoint 4 of 10)

Commits

• d5c9701 feat(protected-content): add canonical custody envelope contracts
• f15854b feat(protected-content): seal custody shares for verified releases
• 401d6d0 feat(protected-content): reconstruct threshold content keys
• 3e3caf2 fix(protected-content): reject invalid X25519 contract keys
• 088e4f7 fix(protected-content): bind exact threshold reconstruction
• 927dfd6 feat(protected-content): define policy and recipient authority
• 58c00c7 feat(protected-content): bind custody epochs and release operations
• 1889994 docs(protected-content): record operational contract boundaries
• 2c2e0dc feat(protected-content): gate node release on durable replay claims
• 854842b docs(protected-content): record custody operation boundary
• 3b07fd4 feat(protected-content): replay exact custody results
• 4bbadb1 docs(protected-content): define canonical custody architecture
• bd2d799 docs(protected-content): record published custody truth
• 29879b2 test(protected-content): label provisional provider retirement guard

[irzhywau]

Two commits were added on top of 29879b25:

• 305354e5 — merge of the updated parent feat/protected-content-contracts (checkpoint 3 tip, CI-green: the bootstrap-DID regression fix and the clippy alignment). One state.md conflict hand-merged: kept this branch's newer custody truth entries, layered in the 2026-08-27 stacked-review progress bullet and the corrected stacking references.
• 2f844cef — fix(protected-content): verify statement signatures strictly. custody_epoch, recipient_authorization, and runtime_release_operation verified their statement signatures with ed25519-dalek verify while every other signed contract in the crate uses verify_strict. Aligned the three sites (plus the then-unused Verifier trait imports); canonical-key validation already rejected non-canonical verifying keys, so this only tightens signature-side malleability. Also carries four provider-capsule Cargo.lock metadata refreshes.

Verified locally at the tip: all source gates (check-wci-alignment.sh, home/browser entropy, close-handshake, vendor-ui --check, product UI source proofs, protected-content-provider-contract-smoke.sh — the provisional-retirement guard — PASS), cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (on cleaned fingerprints), cargo test --workspace — 2079 passed; the only 2 failures are the known macOS mDNS-environment room::direct readiness tests (green on ubuntu CI, as this run confirms).

Review observations for the chain owner (no code changed; details on request):

1. The CEK commitment (SHA256(domain ‖ 0x00 ‖ cek)) is manifest-contained but not cryptographically bound to the envelope or content identity — the same CEK across two envelopes yields an identical, linkable commitment, and a swap is undetectable at this layer. Docs/state.md say "manifest-bound"; mixing in the encrypted-content identity or epoch would make the wording exact.
2. Replay store caps: MAX_NODE_RELEASE_RECORDS = 2048 is unreachable before the 8 MiB state-byte cap; hitting the byte cap makes every new claim fail (Unavailable) until records expire — fail-closed but a self-DoS window with no boundary test at realistic record sizes.
3. ensure_state_dir requires the state dir's parent to be exactly mode 0700 and euid-owned; standard parents (/var/lib, most XDG dirs) make the store permanently Unavailable, and every error collapses to Unavailable, which will be hard to diagnose in the field.
4. A transient error after the claim-only record is persisted burns the operation for the whole claim window (the documented missing operation-resume journal) — noting it triggers on transient HPKE/IO errors, not just crashes.
5. Largest crypto-test gap (self-identified in docs step A): no RFC 9180 known-answer vectors for the HPKE wrapper.
6. reconstruct.rs takes expected_terminal_issuer as a caller parameter — the terminal-receipt trust anchor is external to the contract layer (presumably bound in a later checkpoint; worth keeping visible).

Positives worth recording: exact-threshold binding (required+1 fails), constant-time CEK commitment compare, complete X25519 canonicality validation (low-order/u≥p/high-bit at every entry), #![forbid(unsafe_code)], zero panics in non-test code, owner-only flock+fsync+rename replay-store atomicity with cross-process concurrency tests, and the docs' explicit non-claims are accurate against the code.