Task
Uplift dig-keystore 0.10 -> 0.12, depend on dig-keystore-hardware, and make platform_provider() return the real platform candidate. The node's hardware seam is already fully built and wired to a hardcoded None, so this is one function body plus a dep bump.
Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/1502
Context
crates/dig-node-core/src/seams/key_mgmt/machine_key.rs:270 already composes HardwareBoundBackend::new(FileBackend::new(dir), provider, HardwarePolicy::Optional). Nothing else in the node moves — the author's own doc comment says so.machine_key.rs:609 — pub fn platform_provider() -> Option<Arc<dyn HardwareProvider>> { None }. Replace the body with dig_keystore_hardware::platform_candidates().into_iter().next() (or bind_strongest, if you prefer the ladder to own selection — say which in the PR).machine_key.rs:604-608 now states a falsehood and must be corrected in the same PR: "dig-keystore ships no platform binding — its hardware module forbids unsafe, so the TPM / Secure-Enclave FFI lives in a future workspace member (dig_ecosystem#1693)". That workspace member landed in dig-keystore ed9601a3 / v0.12.0. A stale doc comment on the single seam that gates the feature is exactly how a shipped capability stays dark.crates/dig-node-core/Cargo.toml:199 pins dig-keystore = "0.10"; :499 pins the testing feature the same way. Both move together, and §2.4b applies — bring the crate's other dig-* deps to latest in the same PR.
Scope note — this is the MACHINE key, not DIGLW1/DIGVK1
The epic's named acceptance is dig-app's seed and identity key (tracked separately). This child is included because it is the one place the decorator is already composed and one line from live, and because leaving a seam wired to None behind a doc comment that says the binding does not exist is a durable trap. HardwarePolicy::Optional is correct here and must stay — refusing to boot the peer network over absent hardware would strand every node.
Effort
Medium. Mechanical once the dep cascade resolves; the judgement is only in the policy (already settled: keep Optional) and the dep uplift.
Evidence
- On a real Windows TPM host: the node starts, and the machine key's
blob_tier reads Hardware(WindowsTpm20).
- On a host with no hardware: the node still starts and reports
Software(...) with a reason that is not NotRequested — that reason changing is the proof the seam went live.
cargo tree shows one dig-keystore line at 0.12.
Task
Uplift
dig-keystore0.10 -> 0.12, depend ondig-keystore-hardware, and makeplatform_provider()return the real platform candidate. The node's hardware seam is already fully built and wired to a hardcodedNone, so this is one function body plus a dep bump.Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/1502
Context
crates/dig-node-core/src/seams/key_mgmt/machine_key.rs:270already composesHardwareBoundBackend::new(FileBackend::new(dir), provider, HardwarePolicy::Optional). Nothing else in the node moves — the author's own doc comment says so.machine_key.rs:609—pub fn platform_provider() -> Option<Arc<dyn HardwareProvider>> { None }. Replace the body withdig_keystore_hardware::platform_candidates().into_iter().next()(orbind_strongest, if you prefer the ladder to own selection — say which in the PR).machine_key.rs:604-608now states a falsehood and must be corrected in the same PR: "dig-keystore ships no platform binding — itshardwaremodule forbidsunsafe, so the TPM / Secure-Enclave FFI lives in a future workspace member (dig_ecosystem#1693)". That workspace member landed in dig-keystoreed9601a3/ v0.12.0. A stale doc comment on the single seam that gates the feature is exactly how a shipped capability stays dark.crates/dig-node-core/Cargo.toml:199pinsdig-keystore = "0.10";:499pins thetestingfeature the same way. Both move together, and §2.4b applies — bring the crate's otherdig-*deps to latest in the same PR.Scope note — this is the MACHINE key, not DIGLW1/DIGVK1
The epic's named acceptance is dig-app's seed and identity key (tracked separately). This child is included because it is the one place the decorator is already composed and one line from live, and because leaving a seam wired to
Nonebehind a doc comment that says the binding does not exist is a durable trap.HardwarePolicy::Optionalis correct here and must stay — refusing to boot the peer network over absent hardware would strand every node.Effort
Medium. Mechanical once the dep cascade resolves; the judgement is only in the policy (already settled: keep
Optional) and the dep uplift.Evidence
blob_tierreadsHardware(WindowsTpm20).Software(...)with a reason that is notNotRequested— that reason changing is the proof the seam went live.cargo treeshows onedig-keystoreline at 0.12.