Repository navigation
feat(protected-content): provision installed custody and chain prerequisites - #52
Merged
irzhywau merged 2 commits intoSep 8, 2026
Conversation
…ent the operator surface Promote custody-provider from dev-dependency to dependency so operator provisioning calls the same provision_state_root the provider binary uses; refresh object-provider's lockfile and build-script permissions for the shared-artifacts layout; document the elastos protected-content-config command surface in docs/PROTECTED_CONTENT.md.
…uisites One explicit operator command surface, elastos protected-content-config: create the policy authority key; provision each custody host's inactive state root (the owner-only directory boot registration requires but nothing created) and export its node descriptor; print the Runtime issuer custody hosts must trust; assemble and sign the owner-only 2-of-3 custody composition from three descriptors with canonical ordering, derived operator/failure-domain ids, and random owner state roots; and install the private multi-source Chain configuration with the deployment-proven Base gateway and selector defaults, enforcing the documented 2..=5 distinct-origin evidence rule. Generated files are proven against the Runtime loaders before success is reported, and a group-readable data root stays provisionable since owner-only modes are enforced from protected-content down. Boot now wires reconcile_runtime_custody_viewers_after_decrypt_registration into the decrypt-registration success arm through a warn-and-continue hook, settling viewer records stranded before decrypt came up, and names each absent protected-content provider binary instead of skipping it silently.
This was referenced Sep 7, 2026
This was referenced Sep 29, 2026
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
2 participants
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.
Part of #44 (ELACITY-2297): provision the installed custody and chain prerequisites for the protected-content path.
What this delivers
One explicit operator command surface,
elastos protected-content-config(mirrors thecollaboration-configoffline-authority pattern):create-policy-authority-key— dedicated 32-byte Ed25519 policy authority key, owner-only.provision-custody-node— creates the owner-onlyprotected-content/custody-provider/inactivestate root (the directory boot registration requires but nothing previously created, so custody registration failed every boot on an installed machine) via the sameprovision_state_rootthe custody-provider binary uses, and exports the host's node descriptor (node key, X-Wing custody key, operator/failure-domain labels, local or Carrier-DID transport).show-runtime-issuer— prints the Runtime operation issuer custody hosts must trust.generate-custody-composition— assembles and signs the owner-only 2-of-3 composition from three descriptors: canonical node ordering, domain-separated SHA-256 operator/failure-domain ids, random non-zero owner state roots, byte-canonical JSON, and a full pass through the real Runtime loader before success is reported.verify-custody-composition— re-verifies an installed composition through the same loader.generate-chain-config— installs the private multi-sourcechain-provider.jsonwith the deployment-proven Base defaults (gateway0x09dbe796f40eceffeaccf243c3d758c4c1d8d87d, selector0x54d42821, chain 8453), enforcing the documented 2..=5 distinct-origin evidence rule at provision time so a bad config fails loudly here instead of silently at boot.Boot wiring:
reconcile_runtime_custody_viewers_after_decrypt_registration(previously zero non-test callers) now runs in the decrypt-registration success arm through a warn-and-continue hook, settling viewer records stranded inOpenPending/Active/CleanupPendingbefore decrypt came up.Packaging needed no changes: components.json, setup-source-home, publish-release, the inventory smoke, and the WCI check already carry all three providers; decrypt registration itself was already live from the 0.7 line.
Verification
just test-elastos(provider process binaries built) — green.protected_content_config+ 2 boot-hook tests; the composition happy path is validated end-to-end byload_runtime_custody_composition.cargo fmt --check, clippy clean,git diff --check,scripts/check-wci-alignment.sh,scripts/source-home-provider-inventory-smoke.py,node scripts/home-entropy-check.mjs,scripts/auth-wallet-focus-smoke.sh— all green.docs/PROTECTED_CONTENT.mddocuments the operator surface.Out of scope (remains on #44 / follow-ups)