4d67f56bc44327a6952e6f9d2d066ff4aeef13aa
2453
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 archipelagoandClaude Opus 5
|
4d67f56bc4 |
docs(changelog): curated notes for v1.7.120-alpha
Leads with the reason to take the update: two ports handed anyone who could reach them full control of the node's money. Written for an operator, not a developer — what was exposed, who could reach it, and what to treat as compromised. Includes the gaps rather than burying them: the 5x lifecycle gate was not run, two fleet nodes still share SSH host keys (rotation is a deliberate operator decision, not an oversight), and Core can now reach Tor but is not yet routed through it. create-release.sh hard-fails without this section, so it lands before the release run rather than during it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
8ee81e04c9 |
docs(roadmap): add Phase 12 — Bitcoin node settings, Core/Knots parity
Per the operator: every option umbrelOS surfaces must be reachable in the UI, Knots-only options surfaced separately from the ones Core shares, and network mode a setting whose DEFAULT is Tor rather than clearnet. Scoped as a phase rather than done inline because bitcoind's arguments are currently hardcoded in three places (first-boot-containers.sh, container-specs.sh, apps/bitcoin-knots/manifest.yml) — the same triplication that produced the lnd-ui HTTP 000 defect. There is nowhere for a UI to write, so BTCSET-01 is a settings model those three render FROM, not another restatement. Two constraints recorded up front so they are not discovered late: - Knots-only flags gated to Knots is a CORRECTNESS requirement — offering one on Core yields a node that refuses to start. - Several options are not freely reversible: txindex forces a reindex, prune is destructive and needs a full resync to undo. On a node that is somebody's wallet backend those must be labelled and gated, not silently applied. Any change at all restarts bitcoind, interrupting LND, electrs and the fedimint gateways. Inbound onion is explicitly out of scope: it needs Tor's ControlPort, which is deliberately disabled for security, so the node reaches .onion peers but stays unlisted. The UI must say so rather than imply otherwise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
f04941934b |
feat(tor): give archy-net containers a SOCKS path so Core can use Tor
Enabling half of "Bitcoin Core has no Tor proxy at all", handed over from the app-UI work. Core reported `onion reachable=False, proxy=''` with all 11 peers on clearnet, and the reason was not a missing bitcoind flag: the container sits on the archy-net bridge (10.89.0.0/24 here), so 127.0.0.1:9050 inside it is its OWN loopback. The host's Tor was genuinely unreachable, and no flag on bitcoind could have fixed that alone. torrc now binds a second SOCKS listener on the archy-net gateway. The gateway is DERIVED at runtime via `podman network inspect`, never hardcoded: archy-net is created without an explicit subnet, so podman allocates one. It is 10.89.0.0/24 on this node with no guarantee of that elsewhere, and a hardcoded guess would fail silently — binding SOCKS to an address no container can reach, which looks identical to working. Two deliberate safety properties: - FAIL CLOSED. If archy-net is absent or its inspect output does not parse, no second listener is emitted and SOCKS stays loopback-only. An exposure boundary is not something to widen on a guess. - 127.0.0.1 is accepted FIRST in the SocksPolicy. SocksPolicy applies to every SocksPort, so an accept-list naming only the bridge subnet would have locked the daemon out of its own loopback SOCKS — breaking the node's Tor usage in a way that looks nothing like "we added a listener". The list is accept-loopback, accept-subnet, reject *. This widens Tor SOCKS from loopback-only to the archy-net subnet, which is a real change to the node's exposure surface and was explicitly approved by the operator rather than assumed. Inbound onion for Core remains impossible without reversing the deliberate "ControlPort disabled for security" decision — this is outbound only, and the node stays unlisted on Tor. Not yet wired: bitcoind still has no -onion flag, because the operator wants network mode to be a UI setting with Tor rather than clearnet as the default. Hardcoding the flag in the three places that currently define bitcoind's arguments would be the wrong shape for that, so it is deferred to the settings work rather than done twice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
fbec70069f |
fix(nginx): serve AIUI's absolute /assets/ requests from aiui/assets/
Taking over a parked item from the app-UI work. AIUI's built index.html
emits ABSOLUTE /assets/<hashed> paths, so the browser asks for
/assets/index-BC2fBBaW.js. That lands in the MAIN UI's assets dir, where
it does not exist — the real files are in aiui/assets/. Both of AIUI's
two entry assets 404'd, so the embedded sidebar loaded nothing.
The config already contained a /aiui-assets/ location whose comment names
this exact problem ("AIUI may reference /assets/ without /aiui/ prefix"),
but it only catches requests to /aiui-assets/, a path AIUI never asks
for. It described the bug without fixing it.
/assets/ now falls back to a named location that rewrites into
aiui/assets/ and 404s from there. A fallback rather than copying the two
files up one level, because a frontend deploy replaces web-ui wholesale —
update.rs preserves the aiui/ DIRECTORY, not copies made into assets/ —
so a copy is erased by the very next deploy while this survives one.
Both server blocks (HTTP and HTTPS) are patched; named locations are
per-server, so each needs its own.
Verified on archi-dev-box after reload:
/assets/index-BC2fBBaW.js 200, 305256 bytes, application/javascript
/assets/index-BJkaQ2c4.css 200, 150716 bytes, text/css
/assets/does-not-exist.js 404 (the fallback is not over-broad)
/assets/index--lyLAgu1.js 200 (real main-UI chunks still come from
/assets/vendor-CmYeCqL_.js 200 the main dir — try_files hits them
/assets/index-CiMaoNII.css 200 before the fallback is consulted)
/ /aiui/ /health 200
Hash collision between the two builds is not a concern: Vite hashes are
content-derived, and any main-UI asset that exists is served by try_files
before the fallback runs.
Noted while doing this, not fixed here: the node's own
/etc/nginx/sites-enabled/archipelago is 378 lines BEHIND this repo file
(984 vs 1362) — it predates the IPv6 listener and the @asset_missing
no-store handling, among others. The node was patched minimally in its
own shape rather than overwritten, since a wholesale copy of a config
this diverged is not a safe unattended action.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
archipelagoandClaude Opus 5
|
c4aece4883 |
docs(01-04): on-node verification, and the send half is inert here
Deployed
|
||
|
archipelagoandClaude Opus 5
|
6b3693dcc8 |
docs(state): 01-04 complete; Phase 1 resumed
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
666990c684 |
feat(01-04): expose meshed Lightning peers and the send path over RPC (FED-05)
Task 3, completing 01-04. mesh.lightning-peers returns the peers that have advertised a Lightning URI: filtered, deduplicated, deterministically ordered, and an empty array rather than an error when nobody has — "nobody yet" is a normal state on a fresh node, not a fault. mesh.send-lightning-info advertises this node's own URI to ONE chosen peer. There is deliberately no broadcast form: this discloses the node's payment endpoint, and who learns it is the operator's choice rather than a side effect of being in radio range (T-01-13). It refuses to send when LND advertises no URI, instead of sending an empty one a peer would store as an undialable target. The list-building and target-parsing logic is extracted into pure functions because this file has no handler test harness and the handlers need a live mesh service. That keeps the three contracts that actually matter provable rather than merely readable: - dedup is keyed on identity_pubkey_hex() — the AUTHENTICATING key, lowercased — never the firmware routing key, so a radio contact and its federation twin collapse to one entry (T-01-11) - "newest advertisement wins" compares PARSED RFC3339 timestamps, not strings: 09:30-01:00 is later than 10:00Z while sorting earlier as text, and there is a test that fails if that is ever string-compared - ordering is name-then-contact_id and asserted byte-identical across eight rotations of the input, because a HashMap's iteration order is not stable and a picker that reshuffles between reads means an operator can click a different node than the one they aimed at The peer allow-list is untouched: server.rs has an empty diff and is_peer_allowed_path still occurs 13 times (T-01-15). Verified: cargo test -p archipelago 1087 passed / 0 failed; clippy --all-targets clean in every touched module (two useless_format lints in the new test code fixed, not waived). The SUMMARY records one deviation honestly: Task 1's tests were written alongside its implementation rather than before, so no pre-implementation failing output exists. A mutation test was run in its place — disabling the pubkey validation fails 3 of the 5 tests — which proves the assertions bind, and the mutation was reverted and verified gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
decb7c713b |
feat(01-04): the two Lightning facts the channel-open picker needs (FED-05)
Tasks 1 and 2 of 01-04. This node's own shareable URI, and a mesh message a peer uses to advertise theirs. lnd.getinfo now deserializes identity_pubkey and uris, which its response struct simply did not declare before (RESEARCH.md Pitfall 5). The identity mapping is split into a pure map_identity() so it is testable without a live LND. A pubkey that is not 66 hex characters maps to None rather than being forwarded: the same rule lnd.openchannel enforces, applied where the operator is reading their own node's identity instead of at the moment they try to open a channel. An absent field yields an honest absence — never a fabricated or placeholder identity. MeshMessageType::LightningInfo = 26 is additive on a wire format shared with every fleet node: 26 was unused, so a peer that predates this fails to decode it rather than mis-decoding it as something else. Its payload is deliberately two fields — this rides LoRa, where every byte is paid for on air, and the optional alias is skip_serializing_if so an absent one costs nothing (asserted, not assumed). is_valid_lightning_uri() validates before anything is stored, because this is unauthenticated RF input: 66-hex pubkey, non-empty host, optional numeric :port, exactly one '@'. It deliberately does NOT resolve or dial the host — that would turn a received advertisement into an outbound connection an attacker chose. Two preservation hazards found while wiring MeshPeer.lightning_uri, both of which would have silently emptied the picker: - decode.rs's identity-advert path does a WHOLESALE insert, preserving only advert_name and lat/lon by hand. Reticulum re-emits identity adverts every announce tick, so a stored URI would have been wiped about once a minute. Now preserved, alongside the same guard the name and position already had. - session.rs's refresh_contacts and mod.rs's federation seeding rebuild the peer record wholesale too. Neither carries a Lightning datum, so both now carry the previous value forward rather than nulling it. A malformed inbound URI is rejected before the write, leaving any previously stored good URI intact — otherwise anyone in range could blank out a real peer's picker entry (T-01-12). Verified: 5/5 new lnd::info tests, 18/18 mesh::message_types (5 new), cargo check --all-targets clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
e205f2c34a |
docs(security): prove the delivery path on hardware; close window 15
Controlled test on archi-dev-box with operator approval. The daemon was
stopped first so the reconciler could not repair the state before the
re-exposure was confirmed — without a confirmed 200, the later 401 would
be consistent with the state never having been broken at all.
1. stale conf installed + container restarted -> POST /bitcoin-rpc/
returned 200 with a real block height and Allow-Origin: *
2. daemon started 20:00:36, nothing else touched
3. 20:02:19 reconcile rendered the conf and logged the expected warn
line naming bitcoin-ui/archy-bitcoin-ui, then restarted it
4. POST -> 401, Allow-Origin origin-scoped
5. conf byte-identical to the pre-test known-good, container healthy
Both halves are now proven on real hardware: a05956c4's template (the
gate works) and f6b5245b's delivery path (the gate reaches a container
the reconciler had been skipping).
Also records the operator's decision AGAINST credential rotation — no
macaroon, no Bitcoin RPC password — with the trade it accepts stated
plainly, so it is not silently re-litigated later.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
archipelagoandClaude Opus 5
|
186a2c36c8 |
fix(lnd-ui): manifest declared bridge 18083:80 like the spec did
Second copy of the wiring fixed in
|
||
|
archipelagoandClaude Opus 5
|
b2ed27dcfb |
fix(bitcoin-ui): send no-cache for index.html; pin the rebuilt image
Two things needed for the new UI to actually reach users. The rendered nginx.conf served index.html with only ETag/Last-Modified and no Cache-Control, so browsers applied heuristic caching to it. Confirmed on archi-dev-box: after rebuilding and recreating the container, :8334 and /app/bitcoin-ui/ both served the new markup immediately, but the app iframe in the main UI kept showing the previous UI until a hard refresh. docker/lnd-ui/nginx.conf has always carried this header, which is why only bitcoin-ui showed the stale copy. Using "no-cache" (revalidate) rather than "no-store" keeps the ETag doing its job when nothing has changed. Validated by mounting the rendered config into a throwaway container from the built image and running nginx -t. (An earlier attempt to test it inside the running container was meaningless — conf.d/default.conf is a read-only bind mount, so the copy failed and nginx -t just re-checked the original.) The 8 container::bitcoin_ui tests still pass; their assertions cover the placeholder, the 8332 proxy_pass and the listen directive, none of which this touches. BITCOIN_UI_IMAGE was still pinned to 1.7.84-alpha, so a fresh install would pull a bitcoin-ui from many releases ago regardless of what the OTA ships — first-boot-containers.sh tries the registry image before building from source. Bumped to 1.7.119-alpha, matching the current release, and the image is pushed under that tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
aaa89789d2 |
fix(lnd-ui,bitcoin-ui): OTA-breaking lnd-ui spec, 404 channels link, iframe copy, node URI
All four found by verifying on archi-dev-box rather than assuming.
container-specs.sh: archy-lnd-ui was specified as a BRIDGE container with
SPEC_PORTS="18083:80", but docker/lnd-ui/nginx.conf listens on 18083
directly (it must, to proxy the backend on 127.0.0.1:5678 same-origin).
Recreating from that spec publishes host 18083 to container port 80, where
nothing listens. Reproduced on the node: the app came back with :18083
refusing connections, HTTP 000. This never fired before because the running
containers are created by first-boot-containers.sh, which is host-networked
and never reads this file; the spec is only consulted when self-update.sh
rebuilds a UI image, and that only happens when a file under docker/lnd-ui/
changes — which is exactly what the previous two commits did. So the next
OTA would have taken lnd-ui down on every node. Now SPEC_NETWORK="host"
with no port mapping, matching what actually runs. NET_BIND_SERVICE dropped
with it: 18083 is unprivileged.
lnd-ui channels link: pointed at /apps/lnd/channels, but that route is a
CHILD of the /dashboard record in neode-ui's router, so the real path is
/dashboard/apps/lnd/channels. nginx's SPA fallback returns 200 for the
wrong path, so it failed as vue-router's NotFound view rather than an HTTP
404 — both the Payment Channels card and the Manage Channels button.
Both apps, copy buttons: navigator.clipboard only exists in a secure
context, and nodes serve these apps over plain http; the main UI also
embeds them in an iframe, where the async Clipboard API is separately gated
by the clipboard-write permission policy. Every copy button silently did
nothing there. Added an execCommand('copy') fallback behind a copyText()
helper and routed all six call sites through it.
lnd-ui Node ID: showed the bare pubkey whenever getinfo.uris was empty,
which is the common case — LND only populates uris once it is advertising
an external address. The bare pubkey is not what a peer pastes to open a
channel. The full pubkey@host:9735 URI is now built from the Tor onion
where available, falling back to this node's address, with a hint saying
which and what its reachability is. The QR encodes the URI too.
Verified on archi-dev-box: both images rebuilt and containers recreated
from the specs; lnd-ui and bitcoin-ui both serve 200 with the new assets;
and the RPCs the new tabs depend on all answer on the live node —
getblockstats returns every field the charts read, getpeerinfo returns 11
peers carrying relaytxes and network values the classifier handles.
Note for whoever tests bitcoin-ui's Insights/Peers tabs: /bitcoin-rpc/ now
sits behind auth_request /_session_check (
|
||
|
archipelagoandClaude Opus 5
|
5c9d5dc424 |
docs(state): record the on-node verification outcome and what stayed open
Names the four open items explicitly, including the one that is easy to lose: the reconcile fix is deployed but unexercised, so the node's 401 proves the template and not the delivery path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
5a21b58f69 |
docs(security): record what actually closed :8334, and what it does not prove
The node is closed and verified 401 with origin-scoped CORS. But an
unrelated bitcoin-ui rebuild at 18:36 cleared the stale conf before the
reconcile fix was deployed at 19:06, so the 401 proves a05956c4's
template and NOT the delivery path
|
||
|
archipelagoandClaude Opus 5
|
2684fa7cd1 |
docs(windows): close window 13 — host_secrets observed on a real node
system.stats on archi-dev-box returns host_secrets with verdict 'per-node' and three evidence lines (machine-id anchor 2026-04-09; every SSH host key and the TLS key newer than the anchor). Previously proven against the file contract in unit tests only. Honest limitation: this is one node, not the dev pair — archy-x250-dev has been offline for two days, so the second node is unreachable, not skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
2e68384234 |
fix(lnd-ui,bitcoin-ui): canonical app icon, header stacking, square QR, button parity
Five review fixes across both node UIs. 1. LND now uses the app-store icon. It was shipping its own 182KB lnd.svg while the app store, My Apps and the signed catalog all render neode-ui/public/assets/img/app-icons/lnd.png (catalog.json points at /assets/img/app-icons/lnd.png). Same file is now vendored into the image, so the app header, the launcher and the store agree. That icon is a full-bleed square with an opaque white background rather than a transparent glyph, so it fills the frame and is clipped to the inner radius — exactly how bitcoin-ui frames its own icon — instead of being inset with padding on a dark plate. 2. Header no longer squishes at tablet widths. Both headers had a single 768px breakpoint, so between 768 and 1024 the title and description got crushed against the controls on the right (four status cards on bitcoin-ui) and overlapped. Both now use three breakpoints: fully stacked and centred below 768, logo + title on one row with the controls wrapped underneath below 1024, single row above. The app name and description are centred on mobile. 3. QR codes stay square. .conn-layout is a flex row on desktop and flex items stretch by default, so the white QR plate was being pulled to the height of the fields column and the square QR sat letterboxed in it. The plate is now a fixed square inside a black glass panel that absorbs the extra height, so the panel matches the fields and the QR stays square. 4. Buttons read as one family. The Settings button and both modal dismiss buttons used the flat .glass-button while every other button on the page used .info-card-button; they now all use the latter, via new .compact (inline) and .icon-only (square) variants so the shared style works at button size rather than only as a full-width card. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
ba493fb0fc |
docs(security): write up the Bitcoin RPC proxy that stayed open after it was fixed
The half that landed correctly (LND, clean 401) made the half that did not harder to notice, because the first check an operator would run returns a pass. Records the probes, the three-fact root cause, and the pass condition for re-probing a node. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
7f40fa1e93 |
docs(windows): record the live bitcoin-ui RPC exposure as window 14
Verified live on archi-dev-box, code fix committed in
|
||
|
archipelagoandClaude Opus 5
|
f6b5245b0d |
fix(security): deliver config fixes to a running app the marker calls uninstalled
Found while VERIFYING |
||
|
archipelagoandClaude Opus 5
|
f4a323226e |
feat(bitcoin-ui): add Insights, Peers and Connect tabs for UmbrelOS parity
The Bitcoin UI was one long scroll: sync card, RPC/ZMQ cards and the relay-sharing panel stacked on a single page, with node details hidden in a modal. umbrelOS's rebuilt Bitcoin Node app splits the same surface across a Home/Insights/Settings dock and shows considerably more. Added, all of it additive — the sync state machine, the status-snapshot staleness logic and the relay-sharing panel are untouched and just move inside a tab panel: - Five tabs (Node / Insights / Peers / Connect / Sharing) using the same segmented control as lnd-ui, which becomes a fixed bottom dock under 768px with safe-area padding. - Insights: the four stats umbrel's StatSummary shows (Connections, Mempool, Blockchain Size, Node Uptime), a Latest Blocks strip, and Block Size / Fee Rate / Block Rewards charts — the same three umbrel plots, drawn as CSS bars so nothing has to load a chart library past the CSP's script-src 'self'. - Peers: sortable, filterable table with umbrel's exact columns (Peer, Network, Relay TXNs, In/Out, Connected) plus ping. Network is derived from getpeerinfo's own `network` field, falling back to address matching, so Tor/I2P/CJDNS/Local/Clearnet are labelled correctly. - Connect: RPC and P2P details with a Local/Tor selector, QR codes and per-field copy buttons (umbrel's ConnectionDetails), including its unencrypted-LAN warning on Local. Block statistics come from getblockstats, one call per block for the last ten, cached by height so only the new tip is re-fetched. The live tabs poll only while visible rather than adding a third unconditional 5s timer. Also removed the hardcoded "archipelago123" from copyRPCInfo. That string was never the node's actual RPC password — the real one is a manifest-declared generated secret rendered into this app's nginx upstream and deliberately never sent to the browser — so copying it could only ever mislead. The Connect tab says where the password actually lives instead. qrcode.js is vendored from docker/lnd-ui (same file, already CSP-clean) and added to the Dockerfile's COPY set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
341bff4b44 |
feat(lnd-ui): rebuild the LND app UI with UmbrelOS feature parity
The LND UI was a single scrolling page with a flat gradient instead of a background, a permanently-disabled "Wallet" card, and four tabs buried inside a Settings modal. Everything a node runner actually wants to see — routing revenue, peers, liquidity, activity — was absent. Rebuilt against the feature set of umbrelOS's Lightning Node and Bitcoin Node apps (getumbrel/umbrel-lightning, getumbrel/umbrel-bitcoin), rendered in Archipelago's own idiom rather than copying their visual design: - Real background. bg-web5.jpg was already being COPYd into the image by the Dockerfile and simply never referenced; it now drives the same perspective-layer + 0.8 overlay treatment bitcoin-ui uses. Paths stay relative because the app is served at / on :18083 but under /app/lnd/ when proxied by the host nginx, where absolute /assets 404s. - Glass cards with the masked gradient border, matching bitcoin-ui exactly. - Six top-level tabs (Overview / Channels / Activity / Insights / Connect / Settings) replacing the one-page scroll — umbrelOS's Home/Insights/ Settings dock, widened for Lightning. On mobile the bar becomes a fixed bottom dock with safe-area padding; on desktop it is a segmented control. - Overview: total/lightning/on-chain balances, a Max Send vs Max Receive liquidity bar (Umbrel's framing), and peers/channels/capacity/routing stat tiles. - Insights: routing revenue over 24h/7d/30d from /v1/fees, channel totals, network graph stats, and a sortable+filterable peers table with Umbrel's Tor/I2P/Local/Clearnet classification. - Activity: merged Lightning payments, settled invoices and on-chain transactions on one timeline, filterable by rail. - Connect: the existing lndconnect QR flow, plus a Node ID panel with the pubkey and advertised URI (umbrel's NodeIdModal). - sats/BTC unit switch persisted to localStorage (Umbrel's SatsBtcSwitch). Channel management deliberately links out to the existing Archipelago channels view at /apps/lnd/channels rather than being reimplemented here; this app only shows a read-only channel overview. Sync progress tracks the synced_to_chain/synced_to_graph booleans rather than inventing a block-based percentage, because LND exposes no IBD ratio. All data comes through the existing authenticated GET proxy at /proxy/lnd, so no backend, manifest or nginx change is required. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
a850bb6cdd |
docs(10-06): summary — Phase 10 complete, with the gate-effectiveness caveat
All five KEY-05 layers landed. Records the two things a reader would otherwise get wrong: - the 2 boot_reconciler test failures in the full-suite run are parallel-load flakes (4/4 pass in isolation), not regressions; - layer (b)'s clippy gate is LIVE but not yet EFFECTIVE, because 42 pre-existing warnings already fail the same -D warnings step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
a3283cffb4 |
feat(10-06): enable the entropy lint and supply-chain gates (KEY-05 b/c)
Layer (b) — core/clippy.toml bans rand::random and rand::thread_rng crate-wide, each with a reason naming KEY-05 and pointing at the evidence doc. No CI change was needed: the Rust job already runs `cargo clippy --all-targets --all-features -- -D warnings` from core/, so a disallowed_methods hit is already a build failure. --all-targets covers tests deliberately — a fixture keeping the default is a template for the next production call site. Ordering was asserted before the file was written, not after: the residual count of unmigrated call sites is 0, so this cannot turn CI red for other agents on this shared tree. Layer (c) — core/deny.toml makes the rand major split change-detecting: global multiple-versions = "allow", a per-crate deny-multiple-versions for rand, and a dated grandfather skip pinning =0.9.2 exactly. The tree as it stands passes; a third version or a change to either member fails. Both gates were OBSERVED working, not assumed: - Reintroducing one banned call produced the disallowed_methods error with the reason text reaching the developer at the failure point; reverting returned the residual count to 0. - `cargo deny check bans` exits 0 as-is. Removing the grandfather entry made it exit 2 and print both dependency trees, independently confirming F-07's account of where each rand version comes from. Restored, it exits 0 again. Policy (checkpoint Task 5, human-approved): bans-only. The advisories gate is NOT enabled — it fails builds when a new CVE is published against an existing dep with no local change, which on a tree where several agents push continuously would block everyone at an arbitrary hour, with remediation often meaning a bump to an exactly-pinned crypto dependency. No break-glass procedure exists. F-07's advisory half stays OPEN and is recorded as such. cargo-deny is pinned to 0.20.2 and installed from crates.io rather than via EmbarkStudios/cargo-deny-action, because that action exposes no input to pin the tool version — an unpinned supply-chain checker would reintroduce, at the CI layer, the exact "backend fixed by configuration rather than stated" shape this plan exists to remove. crates.io is also the source vetted at the Task 5 legitimacy gate (EmbarkStudios, repo resolves, ~4.79M downloads). RECORDED HONESTLY: layer (b)'s gate is live but not yet EFFECTIVE. The tree carries 42 pre-existing clippy warnings — unused imports, dead code, ~39 style lints — that are already errors under -D warnings, so that CI step cannot pass today for reasons unrelated to KEY-05. Until a dedicated lint-clearing pass lands, a new banned RNG call would be one error among many rather than a distinctive build-stopper. Pre-existing and out of scope; clearing it right before an OTA would be poor sequencing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
c966395eb9 |
fix(security): never auto-publish the wallet UI proxies as Tor onions
Found while checking whether the /lnd-connect-info leak ( |
||
|
archipelagoandClaude Opus 5
|
0a1d314ffa |
feat(security): add LND macaroon rotation for the /lnd-connect-info leak
Operator tool for the fix in
|
||
|
archipelagoandClaude Opus 5
|
09a1f7621c |
feat(10-06): name every entropy source and guard key draws (KEY-05 a/d)
Closes F-10a. Nothing here fixes a present defect: on the pinned rand 0.8.5, rand::random() and thread_rng() both resolve to a ChaCha12 CSPRNG seeded from getrandom(2). What they lack is a STATED backend — it is fixed by dependency and build configuration rather than by the calling code, with no compile error if that changes. That is the structural shape behind the 2026-07-30 COLDCARD entropy defect, and here the blast radius includes Cashu blinded-key-exchange values, X3DH prekey material, session bearer tokens and a ChaCha20-Poly1305 nonce. Layer (a) — every production key, nonce and token draw now names rand::rngs::OsRng at its own call site. The mnemonic seam is bound to entropy::KeyGenRng, a SEALED allowlist whose supertrait lives in a private module, so the set of RNGs that can drive the master key hierarchy is exactly what one file says it is. This retires the false promise at seed.rs:656: rand::CryptoRng is a marker with no compiler-checked content, and the crate now contains zero impls of it. Layer (d) — key material and AEAD nonces of >=12 bytes run a degenerate-entropy predicate that refuses all-zero, all-identical and wrapping +/-1 counter draws. Nothing heuristic: no entropy estimator, no chi-squared. Each of the three shapes has a false-positive probability computable in closed form (3 * 2^-88 at 12 bytes, 3 * 2^-248 at 32), and a predicate whose false-positive rate cannot be computed cannot be argued safe on a key-generation path. There is deliberately no retry — a retry would paper over the broken RNG this exists to surface. Layer (e) — the kernel-CSPRNG readiness verdict at master-seed generation is now durable (backlog R-09). It was previously computed, logged and thrown away, so a node could never answer after the fact whether its keys were born from a seeded pool. The record holds a schema version, timestamp, verdict and event name — no entropy, no key bytes. Formats and wire shapes are proven unchanged rather than asserted: storage_crypto and the credential store each open a HARDCODED pre-migration ciphertext vector (a same-process round trip would pass even if the envelope had changed), the vector was produced by an independent RFC 8439 implementation so it pins the documented nonce||ciphertext format rather than this implementation's output, and the x3dh prekey bundle and bdhke values keep their field set and order. totp.rs migrates its SOURCE only: the % charset.len() reduction and the 32-char charset are untouched. The bias there is presently zero (32 divides 256) and fixing the latent bias is R-12, which stays deferred. Verified: cargo build clean; cargo test -p archipelago 1068 passed, 2 failed. Both failures are container::boot_reconciler timing tests (second_pass_fires_after_interval, shutdown_terminates_loop) in a file this change does not touch — pre-existing, not caused here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
a05956c4ce |
fix(security): require a session for the LND connect info and Bitcoin RPC proxies
CRITICAL. Two app-UI ports handed unauthenticated callers full control of the node's money. Both verified live on archi-dev-box 2026-08-02 over the fips0 mesh ULA with no cookies. GET /lnd-connect-info returned 200 with the LND ADMIN MACAROON, the TLS cert, the gRPC/REST ports and the node's onion address — a complete remote wallet-drain package, and the onion means an attacker keeps that ability after losing network access. POST /bitcoin-rpc/ reached Bitcoin Core RPC with credentials the proxy injected on the caller's behalf, with a wallet loaded, so wallet methods were reachable too. Both were reachable because ports 18083 (lnd-ui) and 8334 (bitcoin-ui) bind 0.0.0.0 AND sit on the fips0 mesh allowlist in fips/app_ports.rs. Any mesh peer, LAN host or Tailscale peer could take either path. The root cause is one mistaken idea in two places: that a check performed by a reverse proxy is an auth check. It is not — it only holds for traffic that arrived through that proxy. /lnd-connect-info's comment said "nginx validates session cookie (presence check), backend is bound to 127.0.0.1 so only nginx can reach it". Both clauses were false in production: the lnd-ui container runs its OWN nginx on :18083 that proxies straight to the backend forwarding whatever cookies arrived, including none, and that second front door never performed the check the premise named. So authorisation moves to the resource: - /lnd-connect-info now requires a session, like /proxy/lnd/ beside it. The 401 carries CORS headers so the wallet UI shows a readable error rather than an opaque CORS failure. - New GET /auth/session-check returns 204/401 and nothing else, giving container nginx an auth_request gate it can actually use. - bitcoin-ui's /bitcoin-rpc/ is gated by that auth_request. Its `Access-Control-Allow-Origin *` is also gone: on a proxy that injects credentials, it let any page a user visited drive the node's RPC. Preflight is answered before the gate, since OPTIONS carries no cookies. The nginx template is include_str!'d and re-rendered on every reconcile pass, so this ships atomically with the binary. Operators must treat the LND admin macaroon and the Bitcoin RPC password on every affected node as compromised and rotate them AFTER this is deployed — rotating first just re-leaks through the same hole. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
689c4cca1a |
docs(10-04): complete fleet host-secret detection and rotation plan
SUMMARY for 10-04, plus three WINDOWS.md entries (11-13) so the unverified items stay visible at ship time: the rotation never exercised on real hardware, host_secrets never observed in a live system.stats, and the C-3 finding itself — three live nodes still on shared SSH host keys, two of them also sharing a TLS private key, none of them rotated. STATE.md and ROADMAP.md deliberately not touched: both carry other agents' uncommitted work in this shared tree and the orchestrator owns them for this wave. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
a806a658a6 |
docs(10-04): C-3 FAILED — three live nodes share their SSH host keys
Audit checklist item C-3 ("the highest-value check here") is no longer
UNVERIFIED. It failed, and the failure is a live F-03 instance rather than a
theoretical one.
Three distinct fleet nodes — archipelago-1, archy-x250-beta and archipelago —
present byte-identical ECDSA, ED25519 and RSA host key fingerprints. Two of
them (archipelago-1, archy-x250-beta) also present the same TLS certificate,
so they share the TLS private key as well.
Gathered read-only and remotely: ssh-keyscan plus an anonymous TLS handshake.
No node was logged into, nothing was written, nothing was rotated. A weaker
instrument than the checklist's on-node commands, chosen because it needs no
access and therefore covers the reachable fleet rather than two nodes — and it
is sufficient for the FAIL condition, which is any fingerprint appearing twice.
Ruled out the obvious alternative (one machine registered three times on the
tailnet): all three answered live TCP within the same minute, and tailscale
ping resolves them to different physical endpoints on different continents
under different tailnet accounts.
One finding worth more than the count: `archipelago` has a UNIQUE TLS cert
(CN=austin-sapien) and SHARED SSH host keys, because it was renamed and
server.set-name re-mints the cert via regenerate_tls_cert() while touching
nothing else. So TLS uniqueness is not evidence that a node's key material is
per-node — any renamed node gets a unique certificate for free. Checked on TLS
alone, that node would have looked clean. Recorded because it justifies the
audit script reporting the two key classes separately instead of issuing one
node-level verdict.
All three are listed under "shared verdict, deliberately not rotated" with the
reason and the next step. A verification task that remediates is a
verification task that takes a node offline.
Also records what this does NOT establish, each with the evidence still
needed: same-ISO provenance, the script's own verdict on those nodes, that a
rotation preserves the operator's live session on real hardware, that
host_secrets reaches system.stats on a real node, and the four nodes that were
unreachable at scan time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
archipelagoandClaude Opus 5
|
373c3bb302 |
fix(10-04): ship the host-secrets audit unit in the OTA runtime payload
[Rule 3 — blocking] bootstrap.rs installs systemd units from the runtime payload at image-recipe/configs/, but create-release-manifest.sh copies only archipelago-doctor.service and .timer into that directory. The new archipelago-host-secrets-audit.service would therefore never exist on any node: bootstrap looks for it, `src.exists()` is false, and it silently installs nothing. No error, no log line — the whole deployed-node half of 10-04 would have been inert on arrival. Two enumerations of the same list in two languages in two files is the drift that caused it, so the loop now carries a KEEP IN SYNC pointer naming the array in bootstrap.rs, and the redundant `if [ -f doctor.service ] || [ -f doctor.timer ]` wrapper is gone — the per-unit `-f` test inside the loop already does that job, and the wrapper would have skipped the whole block on a tree that had the new unit but not the doctor ones. Outside 10-04's declared files_modified. Taken because the alternative was to ship a deliverable that cannot reach its target and file the gap as a follow-up. Staged by path; no other agent had uncommitted work in this file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
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>
|
||
|
archipelagoandClaude Opus 5
|
78b3ec879b |
docs(01-18): Task 1 deploy verified on archi-dev-box; six-fix sign-off still open
Deployed the frontend to archi-dev-box only (--frontend-only, no fleet, no alpha-tester, no Tailscale, no OTA, no release) and proved all six UIFIX fixes are in the bundle the node actually serves. - Resolved the live chunk set from sw.js first: /opt/archipelago/web-ui/ assets keeps every prior deploy's hashed chunks, so a naive disk grep returns hits from dead chunks and would have produced a false pass (threat T-01-83, and it was a real trap here). - Fetched each live chunk over HTTP from http://archi-dev-box and grepped it: all eight probe strings for UIFIX-01..06 PRESENT. - Real Chromium boot check on the node at 1440x900 and 390x740: app mounts, 0 console errors, 0 page errors, 0 failed requests. - archy-x250-dev recorded as an explicit gap: offline, last seen 2d ago, no MagicDNS record; still has neither this plan set's nor phase 2's frontend. Task 2's six numbered checks are all recorded NOT VERIFIED. They need an authenticated session on the node (UI returns 401 / redirects to /login, and no credential was guessed against a node holding real funds), and two of them are not testable as the node stands: it owns exactly one purchased item (image/jpeg) and has zero video and zero audio content anywhere, so the purchased-video, purchased-music and picture-in-picture checks have nothing to open. No source file modified, no fix applied inline, and STATE/ROADMAP/ REQUIREMENTS deliberately left untouched - UIFIX-01..06 are NOT closed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
0214114c7b |
docs(10-02): summary — probe built and committed, C-6 still UNVERIFIED
Task 1 done. Tasks 2 and 3 are blocked on unmet preconditions and were
NOT auto-approved: no fleet node runs 10-01's gate (installed binary
predates
|
||
|
archipelagoandClaude Opus 5
|
f2f89b5fe3 |
docs(10-02): record C-6 evidence so far — probe-method correction, 3 transports still open
C-6 is NOT closed by this commit and is not marked verified.
Measured (read-only, on-node):
- loopback and self-LAN-IP: auth.isOnboardingComplete 200 (EXPOSED),
seed.status 401 (session enforcement intact) — no stop-the-plan finding.
- /rpc/ returns 404: nginx's second proxy block is not a second door, so
the unauthenticated surface is reachable through /rpc/v1 only.
NOT measured — needs a second machine: LAN, Tor, FIPS mesh ULA.
NOT performed — the KEY-01 refusal check and the fresh-node onboarding
walkthrough. No node runs 10-01's gate yet: the installed binary was built
at 06:37 and
|
||
|
archipelagoandClaude Opus 5
|
257ca7e6ac |
docs(10-06): classify all 43 defaulted-RNG call sites with file:line evidence (KEY-05, F-10a)
F-10a recorded raw grep counts and deliberately declined to classify them. This resolves that: every one of the 43 matches under core/archipelago/src now carries a production/test verdict (evidenced by its file's `#[cfg(test)] mod tests` line), what the drawn value becomes, whether the degenerate-entropy guard applies, and a disposition. Tally: 41 migrate, 2 comment, 0 allow. No site needed an exemption, so the crate-wide ban will have no holes to audit. Two corrections to F-10a, each derived independently with its evidence line: session.rs is 4 production sites not 16 (mod tests begins :471), and mesh/x3dh.rs:100/:114 are u32 prekey identifiers, not key material -- the X25519 secrets come from crypto::generate_x25519_ephemeral() at :99/:113. The enforcement blast radius is pinned with `cargo metadata` output rather than asserted: models, helpers and js-engine are not workspace members, so the two core/models matches are outside the clippy build graph and are recorded as a stated limitation rather than omitted. Requirement: KEY-05. Supersedes R-13, absorbs R-05 and R-09. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
96dba73a16 |
docs(10-04): record D-06 rotation trigger as detect-report-then-apply
Task 1 of 10-04 is a blocking decision checkpoint, rated one-way: rotating a node's SSH host key invalidates every known_hosts entry for it fleet-wide and the old private key is destroyed by the swap. Chosen: detect-report-then-apply. auto-on-boot would fire simultaneous known_hosts breakage across the fleet during an OTA with no operator holding the new fingerprints, and a rotation that fails partway on a remote node (.228 is at a remote site and in real use) needs physical console access. It also cannot be dev-paired, which contradicts the standing verify-on-the-dev-pair- first policy — by the time it has been observed on the dev pair it has already run everywhere. The cost of the chosen option — exposure persists on any node nobody revisits — is bounded by making the verdict visible in system.stats rather than by automation, and by keeping a list in this document of every node that reported `shared` and was deliberately not rotated. Records what the decision binds: detect-only default, --apply inert without --yes, the boot unit carries no apply path, and --apply --yes refuses on any node whose verdict is not `shared`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
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> |
||
|
archipelagoandClaude Opus 5
|
cdad880629 |
docs(10,01): record the summaries for the four completed plans
Demo images / Build & push demo images (push) Successful in 3m15s
Written by the previous session's executors for 01-17, 10-01, 10-03 and 10-05, all of which are complete and whose code is already committed. The session was cut off by a dropped SSH connection before these were staged, so they were sitting untracked. Recording them so the phase history is not lost. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
c5a82cba06 |
fix(credentials): mark the encrypted store so a random nonce cannot fake plaintext
The on-disk format was detected by sniffing the first byte for `[` or `{`.
Encrypted blobs begin with a random 12-byte nonce, so roughly 1 in 128
saves produced a valid encrypted file whose first byte was 0x5B or 0x7B;
those were misread as plaintext JSON, failed `String::from_utf8`, and the
store became permanently unreadable. This was surfacing as a flaky
`test_list_credentials_no_filter`, but it is a real data-loss bug: a node
whose ciphertext happened to start with one of those bytes could not load
its credentials.
Writes now carry a fixed `ARCHYCRED1` marker, which cannot collide with a
random nonce, so detection of the current format is exact.
Legacy unmarked files are detected by SUCCESSFUL AEAD DECRYPTION rather
than by another byte sniff. A verifying Poly1305 tag under the node key is
a cryptographic discriminator (~2^-128 false-positive rate), strictly
stronger than any structural guess — which is why the deferred item's
suggested "keep the first-byte sniff as the legacy fallback" was not the
shape adopted. Plaintext JSON remains the last resort, and is still
reachable on a node that has no node key at all.
An undecodable file now errors instead of returning an empty store, so a
transiently unreadable file is never silently replaced by an empty one
that the next save would commit to disk (CLAUDE.md: migrations never
destroy data). Legacy files upgrade on write, never on read.
Tests drive the collision deterministically via an explicit nonce rather
than waiting on the 1-in-128 draw, and cover all three on-disk
populations, the read-path-does-not-rewrite guarantee, and tamper
rejection. 28 passed, 0 failed.
Closes the 10-01 deferred item.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
archipelagoandClaude Opus 5
|
937d836c53 |
fix(01-05): delete the redundant second periodic federation sync loop (FED-02)
Two near-identical periodic federation sync loops were running side by side. git history shows the overlap was accidental, not load-bearing: the 30-minute loop landed first ( |
||
|
archipelagoandClaude Opus 5
|
dad40c23f1 |
fix(10-03): prove the first-boot TLS key and cert are actually a pair
Parsing each half back proves each is well-formed; it never proves they belong together. A key from one generation beside a cert from another passes both individual parse checks, gets blessed, and then nginx refuses to start at the exact moment the marker claims first boot succeeded. gen_tls() now extracts the public key from each half and compares them before the swap, and needs_tls() applies the same check to what is already installed, so a mismatched pair that reached disk some other way (an older build, a half-finished manual edit) is repaired instead of quietly breaking nginx. Extraction subsumes parsing, so this replaces the separate -noout parse checks rather than adding to them. Kept deliberately in step with regenerate_tls_cert() in core/archipelago/src/api/rpc/system/handlers.rs, which does the same comparison on the running node after a rename. Test harness: the openssl stub keypair now carries the generation it came from, and STUB_OPENSSL_MISMATCH emits a cert from a different one — the pair that passes both parse checks and still breaks nginx. New case 9 covers both directions: fail closed when the mismatch arises during generation, repair exactly once when found already on disk, and no spin on the run after either. 9/9 passing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
ae55db38d4 |
fix(tls): make cert regeneration on rename atomic and validated
regenerate_tls_cert() passed -keyout /etc/archipelago/ssl/archipelago.key and -out .../archipelago.crt, so openssl wrote straight into the files nginx is serving from. If openssl died partway, was killed, or the disk filled, the live key and cert were already truncated — a routine `server.set-name` could take HTTPS down with no way back. Reproduced: the live key goes from a valid 2048-bit PEM to 33 unparseable bytes. Mirror the discipline gen_tls() already uses in the ISO builder: generate into .new siblings of the destinations (same directory, so the final mv is a rename(2) and therefore atomic), parse both halves back with `openssl pkey` and `openssl x509` and compare the extracted public keys to prove they are valid and belong together, and only then swap them in. On any failure the existing key and cert are left byte-for-byte untouched and the error is returned. Staging files are cleared before the attempt and on every exit path, success or failure. Permissions: the staging key is created by `install -m` carrying the live key's own mode and owner *before* openssl writes into it (openssl truncates an existing -keyout file rather than recreating it), so the new private key is never group- or world-readable, not even between generation and a chmod. A live mode that grants group/other any access is not reproduced — the key falls back to 0600 — so the swap can never widen permissions. Cert content and parameters are unchanged: same subject, same SAN construction, same rsa:2048, same 3650 days. This is an atomicity and validation fix, not a crypto change. Testing seam: the hardcoded sudo prefix and absolute paths made this untestable, so the logic moved into a small TlsMaterial struct holding the ssl dir, the openssl binary path and a privileged flag. Production is TlsMaterial::production(); tests point it at a temp dir, drop sudo, and substitute a stub openssl. Against the pre-fix shape the two atomicity tests fail (live key modified; garbage accepted); against this change all five pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
879de59ecc |
fix(10-01): gate identity-mutating onboarding RPCs on provisioned nodes (F-01)
Closes F-01 (Critical) of docs/security/ENTROPY-SEED-AUDIT-2026-07-31.md. seed.generate/seed.restore/seed.save-encrypted/backup.restore-identity/ auth.setup are all in UNAUTHENTICATED_METHODS, and several reach NodeIdentity::from_seed or restore_encrypted_backup, which overwrite identity/node_key unconditionally. One unauthenticated POST from the LAN or from any FIPS mesh peer hijacked a live node's Ed25519 identity, Nostr node key and FIPS transport key. - new api::rpc::onboarding_gate::ensure_onboarding_open: refuses once ANY of is_setup() / is_onboarding_complete() / seed_exists() says provisioned, failing safe on I/O errors. NodeIdentity::key_exists is deliberately NOT a signal — server.rs:63-71 writes a temporary key on every boot, so a gate keyed on it would refuse seed.generate on a never-onboarded node. Pinned by allows_on_fresh_temp_dir_even_though_node_key_exists. - ensure_user_account_exists: the inverse guard for auth.onboardingComplete, which is unauthenticated and sets the flag the gate reads — without it, one call locks a fresh node out of its own onboarding. - seed.restore body extracted to restore_node_identity_from_words so the regression suite drives the real path; seed.verify left open with a written verdict (non-mutating). - refusal text begins "Not supported:" so it survives sanitize_error_message and names the authenticated system.factory-reset recovery path. - per-method rate limits for the four onboarding mutators, sized ~6x the measured client retry budget so a 429 cannot reintroduce the error at the DID-creation screen. First-boot onboarding is untouched: all three signals are false throughout the seed steps, and auth.setup runs last (Login.vue:405-425). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
49345b67ed |
fix(openwrt): clear all 4 clippy lints so the CI -D warnings gate is real
CI (.github/workflows/ci.yml) already runs `cargo clippy --all-targets --all-features -- -D warnings`, but archipelago-openwrt emitted 4 warnings on a clean checkout, so the gate was red by default and enforced nothing. Fixed each lint at the source; no #[allow] added. - clippy::cmp_owned (wan.rs:146) — dropped the .to_string() that built an owned String purely to compare against "1"; &str == &str compares the same content. - clippy::unnecessary_sort_by (wifi_scan.rs:75, :177) — replaced sort_by(|a, b| b.signal.cmp(&a.signal)) with sort_by_key(|n| std::cmp::Reverse(n.signal)). Both are stable descending sorts on signal, so tie order is unchanged. Deliberately NOT -n.signal, which would misorder i32::MIN. - clippy::trim_split_whitespace (wifi_scan.rs:156) — removed the .trim() before .split_whitespace(); the latter already skips leading/trailing whitespace and never yields empty items, so parsing is unchanged. All three are semantics-preserving rewrites: no change to comparison results, sort ordering, or channel parsing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
6ed876376a |
docs(todo): onboarding step to name your node (sets the real hostname)
Backend already exists: server.set-name runs hostnamectl set-hostname and regenerates the TLS cert with a SAN for the new name. This is a UI step. Records the hazard that decides the design: renaming changes both the mDNS .local name and the TLS cert, so a rename mid-flow can drop the user's session in the middle of onboarding — potentially between seed generation and seed verification. Placement is therefore a design decision, with three options laid out (last-before-Done, first, or collect-early-apply-late). Also flags RFC-1123 slugification (users will type "Dorian's Node"), whether the rename propagates to the Reticulum display name and mesh surfaces, the reconnection UX, and whether the step is skippable. Sequenced after the in-flight regenerate_tls_cert atomicity fix, since renaming is exactly the path that fix protects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
0d513a0ef7 |
docs(10-05): record the Core-wallet fleet census — 4 nodes clear, 6 unchecked (D-07b)
Task 3 of plan 10-05, run by the operator over Tailscale on 2026-08-02 using the read-only procedure in KEY-03-SIGNING-POSTURE.md. No escalation: nothing found. Examined and CLEAR (4): archi-dev-box, shorty-s/.228, archy-x250-beta, archy-x250-pa. On every one there is no wallet named `archipelago` — the deleted handler's default wallet_name — `listwallets` returns only the unnamed default, and that default reports blank=true, keypoolsize=0, txcount=0, balance=0. The only named wallets are Fedimint gatewayd-*. The result holds across two container vintages (bitcoin-knots and bitcoin-core), so it is not four copies of one image behaving identically. Not examined (6), recorded with reasons rather than omitted: framework-pt, archipelago-1, archipelago and archy-dev-pa (SSH permission denied — password rotated/not held), archipelago-5 (timed out during banner exchange), and archy-x250-dev (offline). Password auth was deliberately not attempted: several fleet nodes lock PAM quickly on a wrong password, and locking out an in-use production node is a worse outcome than an incomplete census. The conclusion is stated at the strength the evidence supports — no *examined* node holds a wallet the deleted handler created, and no examined node holds any wallet with keys or funds. It is deliberately NOT generalised to "the fleet is clear" while six nodes are unknown. F-13 is closed by deletion regardless: the code that could create such a wallet is gone from every future build. No key material appeared in any output and `listdescriptors true` was never run. Also corrects the now-stale R-04/F-13 entry in UNIFIED-TASK-TRACKER.md, which still described `handle_bitcoin_init_wallet_from_seed` and a watch-only migration as pending work — that code no longer exists. Marks it done-by- deletion and adds the six unchecked nodes as a standing item, flagged as a natural fold-in for KEY-04's on-node work but tracked independently so it does not vanish if KEY-04 is re-scoped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
454388226c |
feat(01-05): surface federation sync failures to the operator (FED-02)
A failed federation sync existed only as a `debug!` line on the node, so a peer that had not synced in days looked identical in the UI to one that synced a minute ago. Now the failure is persisted per peer and rendered. - `FederatedNode.last_sync_error` / `.last_sync_error_at` — the failure-side mirror of the existing `last_transport` / `last_transport_at` pair. - `federation::record_sync_result(data_dir, did, outcome)` — records the message on `Err`, CLEARS both fields on `Ok` so the badge disappears when the peer recovers. Runs under FEDERATION_STORE_LOCK via the `*_inner` load/save convention established by plan 01-01. An unknown DID is a silent Ok that writes nothing, so a peer removed mid-pass is never resurrected by an in-flight sync's error write. Skips the save entirely when nothing changed, keeping the steady state read-only rather than rewriting nodes.json (and contending for the lock) every 90s. - Message truncated to MAX_SYNC_ERROR_CHARS (256), counted in chars not bytes so truncation cannot split a UTF-8 sequence (T-01-18). - The 90s auto-sync loop calls it on both arms; the existing `debug!` line is kept — persisting is additive, not a replacement for logs. - `federation.list-nodes` emits both fields when set, omits them when unset. - NodeList renders a red SYNC badge beside the transport badge on both the trusted-node and peer rows, message + age in the `title` so the row stays single-line. Tests (written first, confirmed failing — 16 compile errors, E0425 on `record_sync_result` and E0609 on `last_sync_error`): - persists_error / success_clears_error / missing_did_is_noop / on_empty_store_is_noop / truncates_long_error - NodeList: badge present when set, ABSENT when unset (the guard against a badge that always renders), and present on an observer peer row. cargo test -p archipelago federation — 42 passed, 0 failed. vitest NodeList.test.ts — 4 passed. npm run build — green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
262998747e |
feat(10-05): report BIP-32 key origin on lnd.create-psbt, and record the honest signing posture (D-07b/D-09)
With Bitcoin Core's wallet deleted, LND's PSBT round trip is the only external-signer path Archipelago has, and D-09's key-origin protection moves from Core descriptors (of which none remain) to the PSBT itself. Adds `psbt_key_origin_report(&str) -> Result<PsbtKeyOriginReport>` to lnd/wallet.rs, reporting `input_count`, `inputs_with_key_origin` and `all_inputs_have_key_origin`. An input counts as carrying key origin when either its `bip32_derivation` or `tap_key_origins` map is non-empty. A PSBT with zero inputs reports false rather than vacuous truth. Parsed with the already-present `bitcoin` and `base64` crates; no dependency added. `lnd.create-psbt` gains an additive `key_origin` object on its response and a `tracing::warn!` with the counts when key origin is missing, because that is the exact condition under which a hardware signer refuses the PSBT. Computed best-effort: a decode failure degrades to `null`, never to an error, so a user's send cannot fail because an inspection helper could not parse something. `handle_lnd_finalize_psbt` and `handle_lnd_create_raw_tx` (which deliberately auto-signs with LND's hot keys) are untouched. Three tests, with fixtures built programmatically from the `bitcoin` crate rather than pasted as opaque base64: with-derivations, without-derivations, and malformed-is-an-error-not-a-panic. KEY-03-SIGNING-POSTURE.md gains an honest per-step coverage map of the fund -> export -> sign offline -> import -> finalize -> broadcast round trip. Of six steps, only the new inspection has automated coverage; steps 1, 4, 5 and 6 have none, and there is no air-gap transport (no animated QR, no .psbt file exchange) — export/import is copy-paste of base64. Untested paths are named as untested. Records the verdict that decides whether any of this is an air gap: on a default node an external signer CANNOT meaningfully sign a PSBT from `lnd.create-psbt`, because LND holds the keys for every input it selects. Evidence: the PSBT is funded from LND's own wallet; `ensure_wallet_initialized` creates a full key-holding wallet via /v1/initwallet; the generated lnd.conf carries no `remotesigner.*` block; and a search of apps/, scripts/, core/archipelago/src and image-recipe/ for remotesigner/createwatchonly/ nochainbackend returns zero matches. No fleet node is provisioned watch-only. What ships is PSBT transport, not air-gapped custody — the gap is provisioning, not plumbing. Adds the standing honesty statement in its own subsection: Lightning channel, revocation and HTLC keys are NOT air-gappable at all. They must sign in real time to answer counterparty commitments; remote signing relocates them to a hardened host, it does not cool them. Also adds a status banner to PSBT-SIGNING-ARCHITECTURE.md recording that its Phase 1 was superseded by deletion rather than delivered, so §0's "single highest-value change" and §2.1's invariant now read against a code path that no longer exists. Banner only; §5.4's honesty table is byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
40b77e392a |
fix(10-03): don't bless a cert minted under an untrustworthy clock
The failure fail-closed cannot catch, because generation SUCCEEDS. This unit runs very early (DefaultDependencies=no, Before=ssh/nginx), long before time has synced. `openssl req -x509` stamps notBefore from whatever the clock says, so on a node with a dead RTC or a flat CMOS battery the cert can be years out: clock ahead -> clients reject it as "not yet valid", a harder failure than the usual self-signed warning; clock behind -> notAfter is already in the past once time syncs. The completion marker was then set and never revisited — a node permanently serving a cert nothing accepts. Finding 1, reported rather than assumed: this image does NOT use systemd-timesyncd. It installs and enables chrony, and chrony-wait.service — the unit that is Before=time-sync.target — is not enabled. So time-sync.target is inert here and ordering After= it would buy nothing. Enabling chrony-wait to make it meaningful would stall boot behind NTP on a node with no network, and these nodes are routinely offline at first boot. Not deadlocking boot outranks cert-date elegance, so the ordering is deliberately left alone. Fixed locally instead, in two parts: 1. Backdate notBefore by 24h so ordinary skew between node and client cannot invalidate a fresh cert. -not_before/-not_after arrived in OpenSSL 3.5 and the rootfs is debian:trixie which ships it, but the capability is PROBED, not assumed — guessing wrong would fail every attempt and brick the node, the exact outcome all of this exists to prevent. Without the flags we simply do not backdate and rule 2 still covers the dangerous case. 2. Refuse to bless a cert dated by a clock outside a plausible window (2026-01-01 .. 2056-01-01). The material stays installed so the node is usable and sshd comes up, but the bad dates are recorded as failed=cert-dates and the cert is regenerated automatically once time syncs. Generation is now driven by need rather than by "is the marker absent", and ConditionPathExists=! is removed from the unit so a node that already completed can still be re-examined — skipping the unit is precisely how such a node stays broken forever. The script exits in milliseconds when everything is fine. Anti-spin is one condition: a date-driven regeneration happens ONLY when the clock is currently plausible. A node whose clock is still wrong re-checks and mints nothing. Regression caught while writing this: driving generation purely by content made needs_ssh() false whenever any host key existed, which would have left an image-baked fleet-shared key in place forever — F-03 reopened. The marker check is back in both needs_ functions and case 1 (which prestages a baked key and asserts it was replaced) is what caught it. Case 8 covers mint-under-wrong-clock, repair-after-sync, and both spin directions. Controls: blessing regardless of clock reddens only case 8 (run1-BAD-DATES-NOT-RECORDED); removing the anti-spin guard reddens only case 8 (SPINNING-reminted-while-clock-still-wrong(1->2)). The second control initially passed against a broken guard because the assertion compared certificate dates, and a re-mint under a frozen clock produces a byte-identical notBefore — the assertion now counts mints, which is the only thing that distinguishes "left alone" from "regenerated again". Not covered here: nodes already deployed from earlier ISOs never receive this script (it is installed by the installer, not by OTA), so fleet remediation for them remains 10-04/OTA work in core/**, which is held by other executors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
9622926868 |
fix(10-05): delete the Bitcoin Core wallet path that duplicated the spending key (F-13, D-07b)
`handle_bitcoin_init_wallet_from_seed` derived the BIP-84 account extended *private* key, stringified it, and imported `wpkh(xprv/0/*)` / `wpkh(xprv/1/*)` into a Bitcoin Core descriptor wallet created with `disable_private_keys=false` and an empty passphrase. That put a second copy of the node's spending key in Core's `wallet.dat`, outside the daemon's Argon2 + ChaCha20-Poly1305 envelope. That duplication into weaker protection was audit finding F-13 (High). Deleted rather than rewritten watch-only (D-07b supersedes D-07/D-07a): - No caller anywhere. Repo-wide search leaves exactly one occurrence of the method name (its own dispatcher registration) and two of the symbol in code (definition + dispatch call); every other hit is prose in docs. - LND is the wallet the product drives. Across neode-ui/src every `bitcoin.*` call is read-only status (getinfo/prune-status/onion); the wallet UI sends via `lnd.sendcoins`. - It never ran on archi-dev-box: no wallet named `archipelago` exists there, and the one loaded wallet reports blank=true, keypoolsize=0, txcount=0. - It was authenticated AND password-gated, so F-13 was key-at-rest duplication, not an exposed endpoint. No migration is performed and none is planned. This removes code, not wallets: nothing on disk is touched, no funds move, no wallet.dat is modified. If a node is ever found holding a wallet this handler created, that is a finding to surface and stop on, not a trigger to auto-migrate. `seed::derive_bitcoin_xprv` loses its only non-test caller and is retained deliberately with `#[allow(dead_code)]` and a stated reason: it keeps its existing test coverage and it is the derivation D-07c's deferred BDK cold vault will need. Records the evidence, the D-08/D-09 consequences and the D-07c deferral in docs/security/KEY-03-SIGNING-POSTURE.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |