2 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