4 Commits

Include renames

Author	SHA1	Message	Date
archipelagoandClaude Opus 5	d15cd58d7f	feat(lnd): rotate Lightning macaroons from the dashboard, and stop stranding BTCPay ... Rotating LND's macaroons was an SSH-only script, which in practice meant it did not happen — while a macaroon is a bearer token with no revocation and no expiry, so anything that ever read one keeps the ability to spend until they are replaced. Settings → Lightning credentials now does it behind the node password, shows a step checklist, and refuses to report success unless it has confirmed the node identity and channel census are unchanged. Three findings from performing a real rotation on a dev node, each fixed here: 1. BTCPay was left holding a dead credential, silently. Its connection string carries the macaroon INLINE (LND's datadir is owned by its container subuid, so btcpay cannot bind-mount the file), and the daemon only regenerates that secret when LND's TLS cert thumbprint changes — which macaroon rotation does not touch. Result: btcpay up, LND up, both healthy, every Lightning payment failing, nothing anywhere saying why. 2. Rewriting the secret is not enough to fix it. `secret_env_hash` makes the change visible as env drift, but the reconcile loop runs `ExistingOnly` at boot AND periodically, and there it deliberately leaves running restart-sensitive apps untouched — observed once per tick for half an hour on the dev node. So this reuses FED-07's `credential_rotated` carve-out via a new default-no-op `ContainerOrchestrator::mark_credential_rotated`, on the same reasoning: restart sensitivity protects apps that are working, and this one is working only in appearance. The shell script cannot reach an in-process flag, so it removes the container and lets desired-state recovery rebuild it. 3. LND stayed locked forever on a loaded node. The unlocker is only served after channel.db/graph.db/wallet.db open, measured at 2m38s on a box running 30 containers; the unlock helper gave up at ~60s. That is not a harmless retry — reconcile records the post-start hook as failed, restarts LND, and the slow open begins again, so the wallet never opens and every LND-dependent app stays broken. The not-ready budget is now ~10 minutes; a genuinely wrong password still exits on the first pass via `all_rejected`. Safety properties worth not regressing: - No macaroon content in any response, error, log line or the polled progress feed — digests and byte counts only. - Rotation unlocks via a new `unlock_existing_wallet_no_wipe`, so there is no code path from "rotate my credentials" to `recreate_wallet_destructively`. A wallet whose password this node lacks fails the rotation with the wallet intact. - Channels are compared as active+inactive totals, not `num_active_channels`, which legitimately dips after any restart while peers reconnect. - Backup verified by file count before anything is deleted. Verified: cargo check + fmt clean, 6 new unit tests and the 6 existing container::lnd tests pass, vue-tsc clean, and the built bundle contains the three new RPC method names (the frontend build can silently no-op). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-08 07:45:51 -04:00
archipelagoandClaude Opus 5	0a1d314ffa	feat(security): add LND macaroon rotation for the /lnd-connect-info leak ... Operator tool for the fix in a05956c4. GET /lnd-connect-info answered unauthenticated callers with the LND ADMIN MACAROON, the TLS cert, the gRPC/REST ports and the node's onion address. Every macaroon on an affected node must be treated as known to an attacker. Rotation removes the macaroon root key from macaroons.db plus the issued macaroon files; LND mints a fresh root key on unlock, so every previously issued macaroon — including any the attacker holds — stops verifying. Coins live in wallet.db and channel state in channel.db, and macaroons are bearer tokens rather than keys, so neither database is touched, opened or moved. Safety properties, in the order they matter: - Detect-only by DEFAULT. --apply additionally requires --yes. - An ORDERING GUARD refuses to rotate on a node whose binary lacks the fix, because the new macaroon would leak through the same door within seconds and the operator would believe they were safe. Overridable only via an explicit --force-unpatched. - It backs up the old material to a 0700 dir OUTSIDE the dir LND rescans, verifies the backup file count matches, and refuses to delete anything if it does not. - It never reads, prints or copies a macaroon's CONTENT. Everything it reports is a SHA-256 digest, so the material is proven changed without disclosing it to the terminal or scrollback. lncli runs INSIDE the container and reads the macaroon off its own disk, so the secret never crosses into this script's output. - It records the node identity pubkey and channel census BEFORE, and aborts loudly if the identity or the OPEN channel total changed. Two deliberate non-assertions, both of which would otherwise produce frightening false alarms on a completely healthy rotation: - wallet.db is NOT asserted byte-identical. btcwallet records chain sync progress inside it, so it legitimately changes on every start. - num_active_channels alone is NOT asserted. It counts channels whose peer is currently online and so legitimately dips after any restart while peers reconnect. The safety invariant is the ACTIVE+INACTIVE total, which is what gets asserted; a changed active count is reported as normal post-restart behaviour. Enumeration runs under sudo rather than as a shell glob: the LND data dir is 0700 owned by the container's mapped uid, so "$LND_DIR"/*.macaroon does not expand in an unprivileged shell — it stays literal, which would have made both the backup and the removal loop silent no-ops. Verified on a live node: sudo find returns 9 files where the glob returns 0. Exercised in detect mode against a real LND on a live node: correctly reported the binary as unpatched, live-probed :18083 as LEAKING (200), read both digests and the node identity, and exited 2 without changing anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 16:28:09 -04:00
archipelagoandClaude Opus 5	0ed9334f15	feat(10-04): let a deployed node report — and fix — fleet-shared host keys ... 10-03 closed the build half of F-03: the ISO no longer bakes SSH host keys or a TLS keypair into the shared rootfs, and first-boot regeneration fails closed. Nodes already in the field receive none of that — the first-boot script is installed by the installer, not shipped by OTA — so a node that hit the old fail-open path is still running key material that every downloader of its ISO also holds, and its completion marker guarantees it will never try again. scripts/security/host-secrets-audit.sh decides, from the node's own disk alone, which of those it is. Four signals in a fixed precedence: missing material can never be shared material; the fail-open fingerprint (marker present plus the literal `WARNING: TLS regeneration failed` / `WARNING: ssh-keygen -A failed` lines the old script emitted) is direct evidence and outranks timestamps and also names WHICH class survived; then key mtime against a first-boot anchor (.secrets-regenerated, falling back to the installer's LUKS key then machine-id). Verdicts are per-node / shared / fail-closed-missing / unknown, and every one of them carries the evidence strings that produced it, each naming the file it was read from. per-node is never claimed from an absent signal. No anchor means `unknown`, and a standing first-boot-secrets.failed record also means `unknown` — a clean mtime is not evidence that generation succeeded. That is T-10-37: a false per-node verdict leaves an exposed node looking clean, which is worse than no verdict at all. Rotation (D-06: detect-report-then-apply, recorded in docs/security/KEY-02-FLEET-ROTATION.md): - --detect is the default and is read-only; it always exits 0, because detection is informational and must never fail a boot. - --apply without --yes writes nothing at all, not even its own verdict file. "Touches nothing" is worth being able to say without a footnote. - --apply --yes refuses unless the verdict is `shared`, so the wrong node cannot be rotated even deliberately. - It stages the full replacement TLS pair AND host-key set before touching anything live and aborts if either fails; records the OLD fingerprints before the swap; does TLS first (a dead web UI is recoverable over SSH, the converse is not); replaces host keys by mv-onto-the-existing-path rather than rm-then-mv, so the directory is never momentarily empty; and RELOADS sshd, never restarts it, so the operator's own session survives its own rotation. bootstrap.rs ships the boot unit through the existing run_runtime_assets promotion and enables it --now, so the verdict lands with the OTA rather than at the next reboot. handle_system_stats gains a host_secrets object read from the on-disk verdict — cheap, never an error however malformed the file, and deliberately carrying no fingerprints, because a payload polled every few seconds does not need digests an operator on the node can already read. tests/first-boot-secrets/rotation-tests.sh: 8 cases against temp roots through the HOST_SECRETS_ROOT seam. Negative controls run and reverted, each reddening exactly one case: dry run writing its verdict file (STATE-DIR-CHANGED); the old fingerprints recorded after the swap instead of before (caught by an ordering observation, not a content comparison — the systemctl stub records whether the file existed at the moment of the first reload); a tolerated generation failure leaving a half-rotated node; and `per-node` claimed with no anchor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 15:03:02 -04:00
archipelagoandClaude Opus 5	527f602322	feat(10-02): add read-only-by-default RPC exposure probe (C-6 / KEY-01) ... - Measures EXPOSURE (auth.isOnboardingComplete) and SESSION ENFORCEMENT (seed.status) separately; the audit's C-6 probed with seed.status alone, which is not allowlisted and returns 401 by design, so its "Fail: 200" criterion could never fire. - Read-only by construction: methods come from a fixed READONLY_METHODS array, never from an argument; the one mutating request is behind --destructive with a red disposable-nodes-only banner. - The refusal check uses the published BIP-39 all-abandon/art test vector, so no real key material is ever generated, handled or printed. - No node address, onion address or credential embedded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 14:19:15 -04:00