DreamLake

Host password authentication

2026-09-13 — reservation API candidate; probes merged

Vault #241, master #247, implementation plan.

Password-only verification merged in CLI #61 and Python #50. Candidate native/npm/Python target and jump authentication passed using disposable Linux users and a private SSHD; sanitized receipt records exact sources and cleanup. This is distinct from package publication, hosted KMS or live Nymph enrollment.

The new backend candidate reserves one password binding, retains exact encrypted old/new revisions and freezes only the dedicated, non-expiring replacement. Shared old entries remain writable. Owner-only pending recovery reads survive original expiry or host deletion; recreated HostIds cannot confirm an earlier operation. Reserve/start/cancel/confirm are metadata transitions and client attestations, not backend SSH execution. Pre-start cancellation remains possible after source changes or host deletion because the immutable reserved state proves no start committed. Started mutations still require explicit recovery resolution. A verified terminal receipt authorizes snapshot collection after 30 days; later legitimate unbinding does not retain obsolete ciphertext forever. Pending/uncertain outcomes have no TTL, and explicit active recovery references defer collection.

Local checks passed: the complete Vault suite (179 tests across 27 files), including 26 reservation/KMS tests and 44 combined binding/identity tests, plus typecheck and Prisma schema validation. KMS tests use the real envelope implementation with a synthetic provider transport and native Mongo; no cloud resource was changed. The existing unrelated Prisma native-type warning remains. Paired high-level password mutation, privileged adapter, explicit verified rollback resolution and live rotation remain required work; do not infer completion from these reservation APIs.

The compatibility follow-up verifies actual registry CLI 0.17.0 and PyPI 0.14.0/0.15.0 over a synthetic real HTTP/native Mongo fixture. Their previews remain readable but omit unknown snapshot counts; server start/resume rejects them with 409 before migration progress when snapshots exist. New clients acknowledge schema 2 and expose separate snapshot and total counts. Required schema ratchets when reservations appear during an existing migration. The deployment order requires disabling migration on every old writer before this backend rolls out. These checks use a synthetic KMS transport, not cloud acceptance.

Paired reservation APIs are merged but unreleased in CLI #64 (b4aefc10) and Python #51 (7167a30e). Backend PR #370 remains a review candidate. CLI full validation passed 982 tests; Python passed 644 with 60 skipped. Both documentation builds passed; Python retained 40 existing warnings. The reusable cross-client runner and published-client compatibility runner use isolated loopback fixtures, with no hosted password mutation. Final backend validation passed 179 Vault tests across 27 files plus typecheck.

2026-09-13 — reviewed design, probe implementation starting

Vault #241, master #247, plan and checklist.

Existing CLI masked/FD saving and Python explicit in-memory saving preserve enrollment independently, but have not proved password authentication. The reviewed next slice adds paired password-only verification and a private loopback SSHD fixture. Password rotation needs a separate reservation and recovery contract; key fingerprints and key coexistence cannot represent it. No password mutation, reservation API or live proof is claimed. Commands remain proposed until implementation and validation are recorded.