fix(pairing): give a user-run client the client half of the pairing handshake

[MichaelTaylor3d]

Closes #403

The gap

control_client::call_control had exactly ONE token source: control::load_token_readonly(), the
master control token. On a .deb install #501 deliberately made that file 0600 root:root inside a
0700 root:root directory, so an ordinary OS user driving the CLI against a root system service was
denied on every token-gated control.* verb. The server side of the #280 handshake was already
complete (pairing.rs: OPEN pairing.request, master-gated control.pairing.approve, OPEN
pairing.poll), and pair.rs implemented the OPERATOR side only. Nothing implemented the client
half, and no client anywhere stored or presented a paired token.

What landed

dign pair connect [--client-name NAME] — the client half, and the only pair verb needing no
token. Requests over the OPEN method (call_open, never call_control), prints the compare-codes
value plus the operator's exact command, polls to a terminal state bounded by the server's own
expires_ms, and on approval persists the scoped token to the invoking user's own state dir
(<user_state_dir>/client-token, 0600 on Unix).

The token ladder in call_control — master when readable -> this user's paired token -> the
master read's error VERBATIM (kind and remedy text both preserved; that message landed in #458 and
is platform-correct).

--client-name is bounded by pairing::MAX_CLIENT_NAME itself (made pub so the client cannot
drift from the server) and an over-long name is REFUSED, never shortened.

No permission is widened

Not one mode changes. build-deb.sh, the systemd unit hardening, /var/lib/dig-node and the master
token are untouched; no group is added and nothing is chmod'd. The paired token is strictly less
powerful than the master token: it cannot drive control.pairing.* and cannot drive
control.chiaPeers.add/.remove, so pairing a CLI user confers neither pairing administration nor
chain authority over the wallet replica. Revocation is unchanged.

Why the ladder is a pure function

select_token(master: io::Result<String>, paired: impl FnOnce() -> Option<String>). The
unprivileged case cannot be reproduced by a test process that is privileged, and a unit test cannot
drop privileges — so the read OUTCOMES are arguments, the pattern #458 established here. paired is
a THUNK rather than an Option specifically so that "rung 1 never consults the store" is
OBSERVABLE: with an Option the file has already been read before the decision, and no test could
tell a correct implementation from one that reads it every time.

Blast radius

gitnexus's index is stale for this repo and returns a false-safe impactedCount: 0, so this was
measured by grep + direct read and is stated as such. call_control has 14 call sites across 5
files (control_cli.rs, control_client.rs, entrypoint.rs, pair.rs, peers.rs); its signature
and error contract are unchanged, and the change is purely additive at rung 2 — a caller that could
authenticate before still authenticates the same way, by the same token, first.

Windows does not regress. The installer grants the interactive user read on the master token, so
rung 1 succeeds there and the ladder never engages. restrict_file is already a no-op on Windows
(the parent dir's inheritable ACL governs), and the 0600 assertion is #[cfg(unix)].

Evidence

cargo test -p dig-node-service --lib -> 759 passed, 0 failed, 0 filtered out. cargo clippy -p dig-node-service --lib --all-targets -> clean, exit 0.

Revert-proof, run for real: reverting ONLY the fallback arm of select_token (to
Err(e) => Err(e)) makes a_denied_master_read_falls_back_to_the_paired_token FAIL with the
PermissionDenied remedy as its panic payload — the test is load-bearing on the decision, not on
plumbing below it. The other seven still pass, which is the point: the fixture varies one rung.

An earlier run also caught a real defect via an existing guard —
no_help_text_exposes_an_internal_ticket_number failed on (#403). in the new clap help. Fixed in
8453bda. (Note for reviewers: cargo reported exit 0 on that failing run; the test COUNT is the
signal here, not the exit status.)

Tests added: a_denied_master_read_falls_back_to_the_paired_token,
with_no_paired_token_the_master_remedy_is_returned_unchanged,
a_readable_master_token_wins_without_consulting_the_paired_store,
the_per_user_store_round_trips_and_is_owner_only, a_blank_store_is_not_a_token,
an_over_long_client_name_is_refused_not_truncated (pinned from both sides: at-bound passes, one
over fails), the_default_client_name_is_within_the_bound,
polling_waits_until_the_servers_deadline_and_then_stops (time pinned to an explicit NOW, not the
wall clock), plus two pair connect parse assertions in the existing entrypoint pair test.

Docs + deps

SPEC.md gains §7.11a (the client verb, the four MUSTs of the flow, the ladder with its
rung-1-must-not-consult rule, and what pairing does NOT grant), and §7.3a now states that the
client-side token is NOT in the machine-wide state dir. README.md does not document dign pair, so
nothing there to update.

§2.4b: all 13 external dig-*/chia-* declarations in dig-node-service were checked against
index.crates.io and every caret range already resolves to the latest published version
(dig-node-control-interface 0.30.0, dig-chainsource-interface 0.3.2, dig-rpc-protocol 0.10.2,
dig-constants 0.13.0, …); the chia-* set is uniformly on the 0.36 line. No drift to fix.

Version already at 0.243.0 from the lane-opening commit; not re-bumped.

[MichaelTaylor3d]

IN PROGRESS — not the verdict. Independent correctness gate, fresh context, head 8453bdadf (8453bdad7e9f7ad533c1290689869bf496f299aa). Posting as I establish things so nothing is lost to a stall.

Confirmed so far (reading only; suite running in my own worktree):

1. The ladder is correct in all four combinations. paired_client.rs:435-446 — Ok(t) => Ok(t) short-circuits before paired() is ever called, so rung 1 structurally cannot consult the store. The thunk claim holds: a_readable_master_token_wins_without_consulting_the_paired_store (paired_client.rs:564) sets a Cell inside the closure and asserts it stayed false. That assertion is at the decision and is not satisfiable by a read-every-time implementation.

2. expires_ms is an ABSOLUTE epoch-ms timestamp, not a remaining-duration. pairing.rs:167 (let expires = created + PAIRING_TTL_MS) and :196. So next_poll_step's now_ms >= expires_ms comparison is dimensionally correct and the loop terminates. Had the server returned a remaining-duration, rung pending would have reported Expired on the first poll and the verb would never have worked — that was worth checking and it is fine.

3. The open-method routing is correct. pair.rs:271 and :289 both use call_open, and control_client.rs:77-83 passes token: None, so no bootstrap deadlock.

4. MAX_CLIENT_NAME is mirrored, not copied. validate_client_name (paired_client.rs:454) reads crate::pairing::MAX_CLIENT_NAME directly; the only change in pairing.rs:685 is const -> pub const. Refusal, not truncation, and the test pins both sides of the bound.

5. No permission is widened. The diff touches 9 files; packaging/, the systemd unit and state.rs are not among them. Nothing chmods a machine-wide path.

Two findings already established (details + file:line to follow in the verdict): corrupted whitespace inside three user-facing string literals in pair.rs, and the rung-3 remedy text not naming the verb this PR just created.

[MichaelTaylor3d]

loop-security — IN PROGRESS, NOT THE VERDICT

Audited head: a7b60df07a86665e6680b8546237f74bf82c27e3 (re-resolved from remote myself after the head moved mid-audit).

I verified the lane's claim rather than accepting it: git diff <merge-base>..<head> -- crates/ at a7b60df is byte-identical in added/removed lines to the same diff at 8453bda — only blob hashes and hunk offsets differ (entrypoint.rs shifted 4 lines by main's #489). And all nine files this audit depends on (control.rs, server.rs, state.rs, pairing.rs, control_client.rs, pair.rs, paired_client.rs, wallet_authz.rs, wallet_mtls.rs) hash identically at both heads. No probe of mine straddled the merge — I ran no build.

CLEARED so far

Trust direction — clean. PAIRED_CLIENT_TOKEN_FILE = "client-token" appears in exactly two places repo-wide, both inside paired_client.rs (:43, :59). Nothing on the daemon side reads it. The server validates a presented token against the root-owned paired-tokens.json in the machine state dir (server.rs:1183, :1224, :1276, :1308, :1459, :1560, :1587 all route through pairing::is_paired_token(&pairing::paired_tokens_path(&state.state_dir), …)), and load_paired_tokens re-reads the file per call. A token planted in a user-writable client-token gains nothing.

Tier gate — fail-closed, and this PR does not weaken it. server.rs:1181 computes paired_ok = !control::requires_master_token(&method) && is_paired_token(...), and requires_master_token defaults true for any unknown method (control.rs:5884 asserts requires_master_token("control.notAThing")). A paired token therefore cannot reach control.pairing.approve/.revoke or control.chiaPeers.add/.remove (control.rs:5828-5829) on either HTTP (:1181) or WS (:1558). This PR changes no gate code.

Ladder cannot fail open at the server. select_token (paired_client.rs:98) falls back on any master-read error, not only PermissionDenied. I could not turn that into a privilege gain: the substituted credential is weaker, and the server — not the client — is the authority. See the non-blocking UX consequence below.

CORS is not relied on. pair connect goes through call_open (control_client.rs:76), which sends no Origin, so server.rs:211's CorsLayer is not in the path and nothing in this PR depends on it. pairing.rs's "readable only by an allowed CORS origin" claim was always browser-scoped; this PR correctly does not lean on it.

client_name cannot smuggle a misleading label. validate_client_name (paired_client.rs:116) uses name.chars().count() > crate::pairing::MAX_CLIENT_NAME — the same expression and the same constant as the server's own refusal at pairing.rs:141, so the client cannot drift below the server bound, and it refuses rather than clips. The stored value stays byte-verbatim and is neutralised at render by render_untrusted.

FINDING 1 — the per-user token store is created world-readable, then chmod'd (MEDIUM, non-blocking on its own but see the verdict)

paired_client.rs:78-84:

• std::fs::create_dir_all(dir)? (:80) — not crate::state::ensure_dir_restricted(dir), so the dir gets 0777 & ~umask (typically 0755) instead of 0700.
• std::fs::write(path, token)? (:82) — not crate::control::write_atomic, and no OpenOptions::mode(0o600). The file is created 0666 & ~umask (typically 0644) containing the bearer token, and only then does restrict_file chmod it to 0600.

The crate's own established discipline for exactly this class of file is three lines away in pairing.rs::save_paired_tokens: ensure_dir_restricted(dir) → write_atomic → restrict_permissions. This new writer uses neither of the first two.

Why the copied shape is newly exploitable rather than pre-existing. control.rs::load_or_create_token_at:326 has the same write-then-chmod pattern, but it is executed by the root daemon into a 0700 root:root dir — no other user can even traverse it, so the window is unreachable. Here the write is performed by an unprivileged user into $HOME/DigNode, a 0755 directory under a 0755 home, which every local account can traverse and inotify-watch. Scenario: on the multi-user .deb server this PR exists to serve, local user mallory spins open("/home/alice/DigNode/client-token") (or watches IN_CREATE); alice runs dign pair connect; between write and set_permissions mallory reads the scoped token and holds it until revoked.

Fix is small and matches the crate: ensure_dir_restricted(dir)? for the parent, and create the file 0600 at open time rather than after the bytes land.

Still open (next)

Blast radius of a stolen/held paired token (the exact non-master control.* set), the Windows/%LOCALAPPDATA% protection claim in restrict_file's doc, pairing.request flood vs MAX_PENDING eviction, and revocation/stale-store behaviour.

[MichaelTaylor3d]

CHANGES-REQUIRED

Head reviewed: a7b60df07a86665e6680b8546237f74bf82c27e3 (resolved from the remote myself). I began at 8453bda; the head moved under me when main was merged in. I verified that is immaterial: git diff --stat origin/main...a7b60df is 9 files / 525 insertions / 6 deletions, identical to 8453bda, and paired_client.rs, pair.rs, control_client.rs and pairing.rs hash byte-identical across the two. Every finding below is anchored to a7b60df.

What I verified as CORRECT — do not re-derive these

1. The ladder, all four combinations. paired_client.rs:439-445. Ok(t) => Ok(t) returns before paired() is ever named, so rung 1 structurally cannot consult the store. The thunk claim is real, not decorative: a_readable_master_token_wins_without_consulting_the_paired_store (paired_client.rs:564) flips a Cell inside the closure and asserts it stayed false — an implementation that read the file every time would pass a master-wins assertion and fail this one.
2. The remedy survives unchanged in kind and text. paired_client.rs:547 asserts both; the kind matters because cli::ExitCode::from_io_error maps it. (Its CONTENT is finding 2 below — that is a different problem from degradation.)
3. The poll terminates, and the units are right. expires_ms is an ABSOLUTE epoch-ms timestamp (pairing.rs:167, created + PAIRING_TTL_MS; returned at :196), so next_poll_step's now_ms >= expires_ms is dimensionally sound. This was the one that could have been silently fatal — had the server returned a remaining-duration, the first pending poll would have compared ~1.7e12 against 300000 and reported Expired immediately, and the verb would never have worked once. It does not. expired and unknown are both terminal at pair.rs:159, and a missing expires_ms degrades to 0, i.e. fails CLOSED.
4. client_name is refused, not truncated, and mirrors rather than copies. validate_client_name (paired_client.rs:453) reads crate::pairing::MAX_CLIENT_NAME directly; the whole pairing.rs change is const -> pub const. The test pins BOTH sides of the bound and additionally asserts the refusal does not echo a shortened form back.
5. call_open, not call_control, for both handshake steps. pair.rs:118 and pair.rs:136; control_client.rs:77-83 passes token: None. No bootstrap deadlock.
6. Nothing widened a permission. The nine changed files do not include packaging/, the systemd unit, or state.rs. No chmod of any machine-wide path; restrict_file is untouched.
7. No regression for a user who can read the master token — rung 1 is the pre-#403 path, byte-for-byte.

Test evidence I observed personally

Own worktree at C:/tmp/worktrees/gate-403-review, not the implementer's.

• Baseline cargo test -p dig-node-service --lib -> 759 passed; 0 failed; 0 ignored; 0 filtered out. The zero-filtered count matters: a filter matching nothing also exits 0.
• Revert-proof REPRODUCED. Replacing the fallback arm of select_token with Err(master_err) => Err(master_err) -> 758 passed; 1 failed, the single failure being paired_client::tests::a_denied_master_read_falls_back_to_the_paired_token. Exactly one test, and it is the one at the decision. Worktree restored from a copy afterwards; git status clean apart from my own scratch files. (Worth recording: cargo's own exit was 101 while the harness line read exited with code 0 — the count, not the status, is what I gated on.)

Findings

#	severity	where
1	blocking	crates/dig-node-service/src/pair.rs:144,155,165 — corrupted whitespace in three user-facing strings
2	blocking	crates/dig-node-service/src/control.rs:553 — rung-3 remedy does not name dign pair connect
3	non-blocking	paired_client.rs:389 — store lands in a PID-keyed temp dir when $HOME is unwritable
4	non-blocking	paired_client.rs:419 — write-then-chmod window
5	non-blocking	control_client.rs:123 — master-tier verbs now return a worse error for a paired user

Findings 3-5 are posted as notes and I will resolve them myself so they do not bar merge. Findings 1 and 2 stay open as the gating threads.

Neither blocking finding is a design objection. The shape is right, the security argument in the PR body holds up, and the tests are genuinely load-bearing rather than decorative — which is not the usual outcome here. What fails is coherence: the verb ships with three of its own user-facing sentences visibly broken, and the message that is supposed to route a user TO the verb still does not mention it.

(Recorded per contract: a same-identity --request-changes is HTTP 422 here, so this verdict is a comment review. The open inline threads on findings 1 and 2 are what bar the merge under required_conversation_resolution.)

[MichaelTaylor3d]

loop-security — IN PROGRESS, NOT THE VERDICT (2/2)

Head audited: a7b60df07a86665e6680b8546237f74bf82c27e3.

FINDING 2 — the per-user token store can resolve into a WORLD-WRITABLE directory, and the writer follows a symlink into it (HIGH, BLOCKING, INTRODUCED-HERE)

paired_token_path() (paired_client.rs:53) is the only call site of state::legacy_state_dir() outside state.rs itself, and unlike state::state_dir() it applies no preference logic — it resolves straight down the cache-dir chain:

paired_token_path()                  paired_client.rs:53
  -> state::legacy_state_dir()       state.rs:153      = config_path().parent()
  -> dig_node_core::config_path()    core/lib.rs:728   = cache_dir().parent()/config.json
  -> cache_dir()/resolve_cache_dir() core/lib.rs:694
       if !dir_is_writable(canonical_cache_dir())
  -> private_fallback_dir()          core/lib.rs:650   = std::env::temp_dir()/DigNode-<PID>/cache

So when the invoking user's $HOME/DigNode/cache is not writable, paired_token_path() is

/tmp/DigNode-<PID>/client-token

/tmp is 1777. The PID is a small integer, and it is directly observable in /proc — no guessing needed.

The module doc at paired_client.rs:47-51 states the store "lives beside the invoking user's own node state … $HOME/DigNode / %LOCALAPPDATA%\DigNode". That claim is not true on this branch of the resolver, and it is the sentence that would stop the next reader checking.

Concrete exploit — deterministic, no race. Mallory is any unprivileged local account.

1. Mallory creates /tmp/DigNode-<pid> (watching /proc for a dign process is enough; the store write only happens after operator approval, so there are seconds-to-minutes of slack). /tmp's sticky bit stops Mallory deleting others' entries — it does not stop Mallory creating a name nobody holds.
2. Mallory plants /tmp/DigNode-<pid>/client-token as a symlink to /home/mallory/loot.
3. Alice's pairing is approved and store_paired_token runs (paired_client.rs:78-84):
   • std::fs::create_dir_all(dir)? (:80) — returns Ok on the pre-existing dir, with no ownership check. Note this also bypasses crate::state::ensure_dir_restricted, which is what every other credential writer in this crate uses.
   • std::fs::write(path, token)? (:82) — open(2) with O_WRONLY|O_CREAT|O_TRUNC and no O_NOFOLLOW, no O_EXCL, so it follows Mallory's symlink and writes Alice's bearer token into Mallory's file.
   • crate::state::restrict_file(path) (:83) chmods the target, which Mallory owns — 0600 mallory:mallory.
4. Mallory reads the scoped token and drives every non-master control.* method.

What that token is worth. The paired tier is everything in CONTROL_METHODS minus the master set — including control.wallet.resetCoinDb (destructive, and deliberately kept paired-reachable, control.rs:334), control.cache.clear, control.hostedStores.unpin, control.wallet.reservations.release, control.wallet.broadcast, control.profile.putBody, control.collateral.margin.set. Not master tier, but not nothing.

Second primitive from the same defect. Point the symlink at a file Alice owns — ~/.ssh/authorized_keys, ~/.profile — and Alice's own process truncates it and writes a 64-hex token over it. That is an arbitrary-file-clobber-as-the-victim.

When the fallback actually fires (I am stating this as a precondition, not claiming it is the default): an account with no usable home — precisely the "dig-app Agent on a server" persona control.rs:544 names as the motivating case — a read-only or full home, systemd ProtectHome=/ReadOnlyPaths=, an NFS home under root_squash, or HOME unset (then platform_user_base() returns ".", core/lib.rs:643) with an unwritable cwd. DIG_NODE_CACHE and TMPDIR also steer this path.

Why INTRODUCED-HERE and not pre-existing. The shape is not new — control.rs:319-327 writes the master token with the same ensure_dir_restricted-then-fs::write pattern, and state_dir() can also land on legacy_state_dir(). But on the .deb install this PR exists to serve, /var/lib/dig-node already exists, so choose_state_dir (state.rs:271-276) returns it and the master token is never on the fallback path. This new store calls legacy_state_dir() unconditionally, so it is the only credential in the tree that still routes through the cache-dir fallback into temp_dir(). And before this PR an unprivileged user on such a box persisted no credential at all.

Suggested fix (small, and it closes FINDING 1 in the same move). Replace create_dir_all with crate::state::ensure_dir_restricted(dir)?, then let _ = std::fs::remove_file(path); (unlinks any planted symlink without following it) followed by OpenOptions::new().write(true).create_new(true).mode(0o600) on Unix. That removes the symlink follow and the world-readable-then-chmod window in one edit. Separately, consider not deriving an auth path from a resolver that can fall back to std::env::temp_dir().

FINDING 3 — revocation works, but a stale store then masks the remedy (LOW, non-blocking, INTRODUCED-HERE)

Revocation itself is clean: pairing::is_paired_token re-reads paired-tokens.json per call (pairing.rs, "Loaded fresh per call so a revoke takes effect on the very next request"), and revoke_paired_token rewrites the store. A revoked token dies on the next request, and a stale client-token cannot resurrect authority because the daemon never consults it.

The residue: after a revoke the user's client-token still holds a dead value, select_token keeps returning it (paired_client.rs:98-107), and every control.* call now returns the server's generic 401 instead of load_token_readonly's rich remedy — the one message that names dign pair connect. There is no dign pair disconnect to clear it. A user stuck in an opaque 401 is a user tempted to chmod the master token, which is the exact outcome this PR exists to prevent. Worth a follow-up: treat a 401 on a paired-token call as "your pairing was revoked, re-run dign pair connect", or clear the store on that response.

[MichaelTaylor3d]

Correction to my verdict comment — line numbers, not substance.

Several file:line refs in the review summary above were taken from the DIFF's own line numbering rather than from the files at a7b60df. The findings and the reasoning are unchanged; the anchors are not. Correct values, verified against git show a7b60df:<path>:

in the summary	correct at a7b60df
paired_client.rs:439-445 (ladder)	paired_client.rs:98-108 (select_token; the Err arm at :104)
paired_client.rs:564 (thunk test)	paired_client.rs:227
paired_client.rs:547 (remedy test)	paired_client.rs:210
paired_client.rs:453 (validate_client_name)	paired_client.rs:116
pair.rs:118 / pair.rs:136 (call_open)	pair.rs:112 and pair.rs:129
pair.rs:159 (terminal states)	pair.rs:161
control_client.rs:123 (ladder call)	control_client.rs:59-60
findings-table rows 3/4/5	paired_client.rs:52, paired_client.rs:82, control_client.rs:60

pair.rs:144,155,165 (finding 1) and control.rs:555 (finding 2) were already correct — the inline threads are anchored at the right places in both cases.

Verdict is unchanged: CHANGES-REQUIRED, gating on the two open threads (pair.rs:144, control_client.rs:59). The other three are resolved and do not bar merge.

[MichaelTaylor3d]

Two of my own corrected anchors were still off by three: the call_open sites are pair.rs:115 (pairing.request) and pair.rs:133 (pairing.poll), not 112/129. Everything else in the correction table checks out against a7b60df — validate_client_name at :116, the two cited tests at :210 and :227, the terminal-state arm at pair.rs:161.

[MichaelTaylor3d]

loop-security VERDICT: CHANGES-REQUIRED

Head audited: a7b60df07a86665e6680b8546237f74bf82c27e3 — re-resolved from remote myself with gh pr view 498 --json headRefOid after the head moved mid-audit. I verified rather than accepted the lane's claim that the delta was unchanged: git diff <merge-base>..<head> -- crates/ at a7b60df is byte-identical in added/removed lines to the same diff at 8453bda (only blob hashes and hunk offsets differ), and all nine files this audit depends on hash identically at both heads. Read-only throughout: no build, no edit, no worktree, no shared checkout touched.

---

1. The reachability answer, enumerated

Who can reach the node's privileged control.* surface after this change that could not before?

#	Principal	Tier	Status
P1	root / Administrator on the host (can read the master control token)	MASTER	Unchanged by this PR
P2	Any holder of an operator-approved paired token	ordinary (non-master)	Already non-empty before this PR. pairing.request / pairing.poll are OPEN and unauthenticated on both planes (server.rs:1117, :1573), so any process that can reach the loopback control port could already run the whole handshake. The one gate is the operator approving it with the master token
P3	The dign CLI run by an ordinary OS user	ordinary	The intended addition. It joins P2 — it does not create a new tier. Correctly gated on the same operator approval
P4	(UNINTENDED — F2) Any unprivileged local user, where the invoking user's home cache dir is unwritable	ordinary	Steals the victim's token deterministically via a pre-planted symlink under /tmp. Unix only
P5	(UNINTENDED — F1) Any unprivileged local user who can traverse the victim's $HOME/DigNode	ordinary	Wins the window where the store is 0644 and already holds the token

Verdict on the PR body's hypothesis. On the authorization plane it survives refutation: the set of principals is unchanged, and nothing gains MASTER tier. The change admits a new client program into an existing, operator-gated flow. I attacked the ladder, the trust direction and both wallet planes and could not construct a master-tier gain.

Where it fails: the set is not exactly the intended one, because the new credential store adds P4 and P5. Neither reaches master tier — server.rs:1181/:1558 and wallet_authz.rs:218 hold — so neither gets pairing administration or chain authority over the wallet replica. Both get the ordinary tier, which is not nothing: control.wallet.resetCoinDb (destructive, deliberately paired-reachable, control.rs:334), control.cache.clear, control.hostedStores.unpin, control.wallet.reservations.release, control.wallet.broadcast, control.profile.putBody, control.collateral.margin.set.

---

2. Findings

BLOCKING

F2 — the token store can resolve into a world-writable directory and the writer follows a symlink into it. HIGH. INTRODUCED-HERE. Unix only.

paired_client.rs:53 → state::legacy_state_dir() (state.rs:153) → config_path() (dig-node-core/src/lib.rs:728) → resolve_cache_dir() (:694) → on an unwritable home, private_fallback_dir() (:650) = std::env::temp_dir()/DigNode-<PID>/cache. So paired_token_path() becomes /tmp/DigNode-<PID>/client-token; /tmp is 1777 and the PID is readable from /proc. store_paired_token then does create_dir_all (accepts a foreign-owned existing dir, :80) and fs::write (open(2) with no O_NOFOLLOW/O_EXCL, so it follows a planted symlink, :82), and restrict_file chmods the attacker's target (:83). Full chain, preconditions and the arbitrary-file-clobber variant are in my second interim comment above.

paired_client.rs:53 is the only legacy_state_dir() call site outside state.rs, and unlike state_dir() it applies no preference logic — which is exactly why the master token stays safe in /var/lib/dig-node on a .deb box while this store does not.

F1 — the store is created world-readable, then chmod'd. MEDIUM. INTRODUCED-HERE.

paired_client.rs:78-84 uses create_dir_all (dir gets 0755, not ensure_dir_restricted's 0700) and fs::write (file gets 0644 containing the bearer token) before restrict_file narrows it to 0600. The crate's own discipline for this exact class of file is three lines away in pairing.rs::save_paired_tokens: ensure_dir_restricted then write_atomic then restrict_permissions. The copied control.rs:326 shape is unreachable there because the root daemon writes into a 0700 root:root dir; here an unprivileged user writes into a 0755 dir every local account can traverse and inotify-watch.

One edit closes both: crate::state::ensure_dir_restricted(dir)? instead of create_dir_all; then let _ = std::fs::remove_file(path); (unlinks a planted symlink without following it); then create with OpenOptions::new().write(true).create_new(true).mode(0o600) on Unix. Separately worth reconsidering: an auth path should probably not derive from a resolver that can fall back to std::env::temp_dir().

NON-BLOCKING

• F3 — a stale store masks the remedy after a revoke. LOW. INTRODUCED-HERE. Revocation itself is correct (is_paired_token re-reads the store per call, so a revoke bites on the very next request). But select_token (paired_client.rs:98) keeps returning the dead token, so the user sees a generic 401 instead of load_token_readonly's remedy naming dign pair connect, and there is no dign pair disconnect to clear it. A user stuck in an opaque 401 is a user tempted to chmod the master token — the outcome this PR exists to prevent.

• F4 — the OPEN pairing plane is not rate-limited, and a flood evicts the legitimate pending entry. MEDIUM. PRE-EXISTING, severity elevated by this PR. server.rs:1117 answers pairing.request/.poll and returns before the control_ingress_admits limiter at :1150, which lives inside the is_control_method branch. MAX_PENDING = 32 evicts the oldest unapproved entry (pairing.rs:172-182), so an attacker looping pairing.request evicts a legitimate pair connect within milliseconds, every time. No token is gained (approve is master-gated), but pairing is now the only route to control.* for an unprivileged user, so a pre-existing nuisance becomes "the feature is unusable while the attacker runs". Local-only in the default loopback posture; remotely reachable under DIG_NODE_ALLOW_REMOTE=1. Recommend a follow-up ticket.

• F5 — pairing_id is both the approve handle and the poll bearer. MEDIUM. PRE-EXISTING. Entropy is fine: random_hex(16) = 128 bits, OS CSPRNG, fail-closed (pairing.rs:151-165). The issue is where it travels. sudo dign pair approve <pairing_id> puts it in the operator's argv — world-readable at /proc/<pid>/cmdline — plus sudo's auth.log entry and shell history. A local reader can then poll faster than the client's 3s POLL_INTERVAL and take the once-only token; the client reports "it was never approved, or the node restarted" and the user simply retries, so the theft is invisible. This pre-dates the PR (the extension flow has it identically), but the new pair connect banner (pair.rs:123-131) newly routes the id through a human channel — the extension flow never needed to, since the operator read the id from the node's own list output. Worth a ticket: print only the CODE and let the operator approve by code or list index, so the poll bearer never leaves the requesting process.

• F6 — garbled user-facing strings. Cosmetic, not security. INTRODUCED-HERE. pair.rs:144, :154, :164 contain literal 26-space runs mid-sentence ("...with no elevation. The <26 spaces> operator can revoke it...") — a lost line continuation, confirmed with cat -A on the blob. Flagging for the correctness gate; not a security matter.

---

3. Areas checked and clear

• Trust direction — clean. client-token appears in exactly two places repo-wide, both in paired_client.rs (:43, :59). No daemon-side reader exists. The server validates a presented token against the root-owned paired-tokens.json in the machine state dir on every plane (server.rs:1183, :1224, :1276, :1308, :1459, :1560, :1587). A token planted in the user-writable store gains nothing.
• Tier gate — fail-closed, untouched. paired_ok = !requires_master_token(&method) && is_paired_token(...) (server.rs:1181 HTTP, :1558 WS); an unknown method defaults to master (control.rs:5884). The chiaPeers.add/.remove chain-authority path is master-only (control.rs:5828-5829).
• Sage-parity wallet plane — untouched and correct. wallet_authz.rs:218 gates MasterOnly on ct_eq(tok, master) alone; master_tier_control_equivalent (:146) resolves the aliases through the same requires_master_token, so add_peer/remove_peer cannot be reached with a paired token. :214 fails closed on a blank master token. This PR changes no line here.
• Ladder ordering / fail-open. select_token (paired_client.rs:98) falls back on any master error, not only PermissionDenied. I could not turn that into a privilege gain — the substituted credential is strictly weaker and the server, not the client, is the authority. The worst case is dign pair approve sending a paired token to a master-only method and getting a generic 401 instead of the elevation remedy: a UX regression, folded into F3.
• CORS not relied upon. pair connect uses call_open (control_client.rs:76), which sends no Origin, so server.rs:211's CorsLayer is not in the path at all. Nothing here leans on it — correctly, since a native local process is not a CORS request.
• client_name cannot smuggle a misleading label. validate_client_name (paired_client.rs:116) uses the same chars().count() expression against the same pairing::MAX_CLIENT_NAME the server refuses on (pairing.rs:141), so the client cannot drift below the server bound; it refuses rather than clips; the value stays byte-verbatim and is neutralised by render_untrusted at display. The const to pub const widening exposes a bound, not a secret.
• Windows. restrict_file is a documented no-op off Unix, and its rationale cites the service-run harden / the installer — neither of which touches %LOCALAPPDATA%\DigNode, so the stated mechanism is not what protects this new path. What actually protects it is Windows' default per-user profile DACL, inherited by create_dir_all: adequate on a default host, but incidental rather than established by this code. F2 does not apply on Windows, where %TEMP% is per-user.
• Secrets. No key, token, credential, projectId or PAT introduced, logged or committed. The paired token is never printed — only its path is (pair.rs:141-147).
• Dependencies. None added or changed; the only manifest delta is the version bump to 0.243.0.

---

4. What gates

F2 and F1 only. They share one three-line fix in store_paired_token. Everything else is a follow-up ticket, not a merge gate.

I ran no build and no test — this verdict rests entirely on reading the diff and the surrounding code at a7b60df. gitnexus was not used: its registered indexes point at primary checkouts and are stale here, and a stale index returns a false-safe impactedCount: 0, so I used grep plus direct reads throughout and say so.

For the orchestrator: this PR is DRAFT and was CONFLICTING at 8453bda (the lane has since merged main). Re-gate scope on the fix is loop-security only, over paired_client.rs.

[MichaelTaylor3d]

fix lane — progress (head e9783db)

Read the 04:58Z loop-security verdict, both corrections, and the two open review threads. Verified every blocking finding against the tree at e9783db before changing anything.

All four blocking findings are already fixed at e9783db (the previous fix lane pushed the code and then died at the session limit without replying to or resolving the threads):

finding	state at e9783db
security F2 — store resolves into a world-writable dir, writer follows a symlink (HIGH)	fixed — paired_client.rs:53-99 resolves from platform_user_base() and REFUSES an unresolvable base; paired_client.rs:145-160 unlinks then create_new(true).mode(0o600). Tests the_store_resolves_from_the_per_user_base_and_never_the_temp_fallback (:355), an_unresolvable_per_user_base_refuses_rather_than_writing_to_the_cwd (:388), the_store_is_created_exclusively_and_never_follows_a_planted_symlink (:423)
security F1 — created world-readable then chmod'd (MEDIUM)	fixed by the same edit — ensure_dir_restricted + mode at open(2) time, no post-hoc chmod (paired_client.rs:142-160)
review thread a — corrupted 26-space runs in three user-facing literals (pair.rs:144/155/165)	fixed — the four strings are lifted to waiting_banner/paired_message/EXPIRED_BEFORE_APPROVAL/terminal_status_message (pair.rs:172-201) and asserted by the_user_facing_pair_strings_have_no_lost_line_continuation (pair.rs:275)
review thread b — rung 3 remedy does not name dign pair connect (control_client.rs:59)	fixed — remedy_for_unreadable_token unix branch now leads with the unprivileged step (control.rs:553-556), operator verbs kept, windows branch unchanged; asserted one-sidedly at control.rs:6417-6427

Next action: git merge origin/main (Cargo.toml → the pre-assigned 0.250.0, Cargo.lock from main then cargo update -w --offline), then cargo test -p dig-node-service --lib in the background and check the test COUNT, then reply + resolve both threads.

No production code changed by this lane so far.

[MichaelTaylor3d]

fix lane — DONE, ready for the security re-gate

head 5e5bcb5 · version 0.250.0 · 0 unresolved review threads · cargo test -p dig-node-service --lib = 789 passed, 0 failed, 0 filtered out · cargo clippy --lib -D warnings clean · cargo fmt clean.

Every blocking finding, verified against the tree rather than against a comment

finding	verdict	evidence at 5e5bcb5
F2 — store resolves into a world-writable dir and the writer follows a symlink (HIGH, BLOCKING)	fixed at e9783db	paired_client.rs:76-99 resolves from dig_node_core::platform_user_base() — legacy_state_dir() and therefore the temp_dir()/DigNode-<PID> branch are gone from this path — and REFUSES when no per-user base exists rather than writing to .. paired_client.rs:145-160: unlink (which deletes a link rather than following it) then OpenOptions::create_new(true).mode(0o600), so O_EXCL refuses any pre-planted path including a symlink. Tests: the_store_resolves_from_the_per_user_base_and_never_the_temp_fallback (:355), an_unresolvable_per_user_base_refuses_rather_than_writing_to_the_cwd (:388), the_store_is_created_exclusively_and_never_follows_a_planted_symlink (:423, #[cfg(unix)] — so it does NOT execute on this Windows host and its green is not evidence here; the exclusive-create path itself is exercised cross-platform by re_pairing_replaces_this_users_own_store at :457)
F1 — created world-readable, then chmod'd (MEDIUM)	fixed by the same edit	ensure_dir_restricted(dir) for the parent and the mode applied at open(2) time; no fs::write, no post-hoc set_permissions, so there is no window to narrow (paired_client.rs:142-160)
thread a — 26-space runs in three user-facing literals (BLOCKING)	fixed at e9783db, guard tightened by this lane	the four strings are named items (pair.rs:172/182/192/197), each a \-continued sentence. See the note below — the original guard was not load-bearing against the second form of the same defect
thread b — rung 3 remedy does not name the verb this PR created (BLOCKING)	fixed at e9783db	remedy_for_unreadable_token unix branch leads with run \dign pair connect` before the operator verbs (control.rs:553-556); operator sentences byte-identical; windows branch untouched; error kind still set by the read, not the message. Two-sided assertions at control.rs:6663-6674`
F3 (stale store masks the remedy), F4 (open pairing plane unlimited), F5 (pairing_id in argv)	non-blocking per the verdict	unchanged; follow-up tickets, not merge gates

The one real defect this lane found: the whitespace guard was half-blind

Proving thread a's test load-bearing by reverting only its fix showed it PASSED on the reverted string. A lost \ continuation emits the source's indentation as newline + nine spaces, not as an interior run, and the assertion trimmed the start of every line before checking — so it could see "a b" and not "a\n b", which prints just as raggedly. It pinned one form of a two-form defect.

Tightened at 014fe3d: prose strings must carry no leading whitespace, and the banner — the one string with a legitimate indent — is checked against exactly its four-space command indent rather than waved through. Red confirmed on the reverted string (1 test, prose must not be indented), green once restored. No production code touched.

Also committed at 205211b: cargo fmt on paired_client.rs, which the previous lane left unformatted — the Rustfmt gate would have failed on it.

Merge

Merged origin/main twice (it moved to 0.246.0 mid-lane with #494). Both times the only conflicts were Cargo.toml's [workspace.package].version — resolved to the pre-assigned 0.250.0, every other hunk of main verbatim — and Cargo.lock, taken from origin/main then cargo update -w --offline, which relocked exactly one package (dig-node-service → 0.250.0) and moved no dependency line. No source conflicts; control.rs, control_cli.rs, SPEC.md and the dig-wallet sage files auto-merged.

Re-gate scope

Production code changed by this lane: none. The two commits are a test-only tightening (pair.rs test module) and a whitespace-only rustfmt (paired_client.rs test module), plus the two merge commits. So the security re-gate is still loop-security over paired_client.rs's store_paired_token/paired_store_dir as the 04:58Z verdict scoped it — nothing this lane did widens it.

PR remains DRAFT and unmerged.

[MichaelTaylor3d]

orchestrator bc2a88 / loop-security scoped re-gate started on 5e5bcb5 at 2026-09-02T17:31Z

[MichaelTaylor3d]

loop-security — scoped re-gate STARTED

IN PROGRESS — not the verdict.

Head resolved from the remote myself: e70063e3cc8269eea16a10936483cd5266c744af (draft, base main).

Scope of this round (scoped re-gate, not a full re-audit):

1. Verify F1-F4 from the 04:58Z verdict against the tree at this head, not against the fix lane's table.
2. Revert-proof F2 (world-writable store dir / symlink-following writer) in my own detached worktree — comment out the guard, run the discriminating test, confirm a non-zero-count FAIL, restore.
3. Confirm both reviewer threads are genuinely resolved (unresolved=0 via GraphQL).
4. Confirm 5e5bcb5..e70063e is a pure main merge (nothing outside Cargo.toml/Cargo.lock), and re-read the version from disk.
5. Audit only what is NEW in e9783db..5e5bcb5 on the pairing/store path — file mode on create, TOCTOU between unlink and create_new, traversal from a user-controlled base.

Working in my own detached worktree at C:/tmp/worktrees/e93-sec498; the primary dig-node checkout is read-only for me (git objects only). Findings get posted as they are established.

[MichaelTaylor3d]

loop-security — IN PROGRESS, not the verdict (1/2)

Head audited: e70063e3cc8269eea16a10936483cd5266c744af (re-resolved from the remote myself). Read-only against the primary checkout; all work in my own detached worktree C:/tmp/worktrees/e93-sec498. Revert-proof still running — posted separately.

Item 3 — the merge commit is clean. CONFIRMED.

git diff 5e5bcb57 e70063e3 differs from main's own delta git diff b9979d83 bfaa79de by 27 lines total, and every one of them is either the Cargo.toml/Cargo.lock version line or a SPEC.md hunk-header offset:

• Cargo.toml + Cargo.lock: main's 0.246.0 -> 0.247.1 is not applied, because the branch already carries a higher assigned version.
• SPEC.md: one hunk header shifted @@ -3229 @@ -> @@ -3292 @@, because the PR added lines earlier in the file.

Zero source lines. The merge introduces no code.

Version, re-read from Cargo.toml on disk (line 35): 0.250.0. The main it merged (bfaa79d) was 0.247.1. Note origin/main has since advanced to 8089a1f1 at 0.252.0, so 0.250.0 is now BELOW main and the version gate will read green against a stale base — this branch needs a rebase and a re-bump above 0.252.0 before merge. Flagging for the orchestrator; it is a merge-mechanics item, not a security finding.

Item 2 — review threads. CONFIRMED RESOLVED, and the fixes are real.

GraphQL (not the UI): reviewThreads.totalCount = 5, unresolved = 0.

I checked the two BLOCKING ones as fixes rather than as resolutions:

• pair.rs:144 — corrupted whitespace in user-facing literals. Fixed. The four strings are now named functions (waiting_banner, paired_message, EXPIRED_BEFORE_APPROVAL, terminal_status_message) and no interior 3+ space run survives in any of them. The guard the_user_facing_pair_strings_have_no_lost_line_continuation (pair.rs:275) was tightened by the lane beyond what I asked for: it now fails on leading indentation as well as a mid-line run, with waiting_banner the single opt-in exception at exactly four spaces. That is the correct tightening — a lost \ continuation emits leading indentation just as readily as a mid-line run, and the original guard could not see the first form.
• control_client.rs:59 — rung 3 did not name the verb this PR created. Fixed at control.rs:555: the unix branch leads with run `dign pair connect` as THIS account before any operator verb. Two-sided assertions at control.rs:6668 (must contain run `dign pair connect```) and `:6672` (must NOT contain sudo dign pair connect`` — prefixing it would recreate the elevation dead end). The windows branch is untouched and the error KIND is still set by the read, not by the message.

Nit, not a finding: control.rs:6059 carries a 14-space interior run in an assert_eq! failure message. It is a test message, not user-facing, and out of this PR's whitespace scope.

Item 4 — path traversal on the store path. CLEAR.

paired_token_path() takes no argument and both path components are compile-time constants — PAIRED_STORE_FOLDER = "DigNode" (paired_client.rs:48) and PAIRED_CLIENT_TOKEN_FILE = "client-token" (:43). --client-name never reaches the path; it goes into the pairing.request JSON body only (pair.rs:115). There are exactly three call sites outside the module (control_client.rs:62, pair.rs:132, :133) and none passes a caller-supplied path. No traversal primitive exists.

The token is also never printed: on success Outcome carries token_path, not the token (pair.rs:135-137).

[MichaelTaylor3d]

loop-security — IN PROGRESS, not the verdict (2/2): F2 REVERT-PROOF, executed

Head: e70063e3cc8269eea16a10936483cd5266c744af.

The problem with revert-proofing F2 on this host, and how I got around it

the_store_is_created_exclusively_and_never_follows_a_planted_symlink (paired_client.rs:421) is #[cfg(unix)]. This is a Windows host, so that test does not compile in, does not run, and its green says nothing about the HIGH half of F2. re_pairing_replaces_this_users_own_store (:457) does run cross-platform but is not discriminating — fs::write overwrites happily, so it passes under the reverted code too.

So I ran the primitive on a real Linux kernel instead (WSL2 Ubuntu, kernel 6.6.87, rustc 1.98.0), on a native ext4 path (/tmp, not /mnt/c — drvfs does not have Unix symlink semantics). I reproduced both bodies verbatim: the fixed one copied from paired_client.rs:139-162 at this head, and the reverted one being fs::write(path, token) + restrict_file, which is exactly what shipped before e9783db. Same fixture as the crate's own test — a victim file containing PRECIOUS, a store dir, and client-token planted as a symlink to it.

[fixed] call result      : Ok(())
[fixed] victim contents  : "PRECIOUS"
[fixed] store still link : false
[fixed] store mode       : 600
[fixed] SYMLINK FOLLOWED : false

[reverted] call result      : Ok(())
[reverted] victim contents  : "scoped-token"
[reverted] store still link : true
[reverted] store mode       : 600
[reverted] SYMLINK FOLLOWED : true

The guard is load-bearing and the fix is real. Under the reverted body the bearer token is written straight THROUGH the attacker's symlink into the victim file, and the store path is still a symlink afterwards. Under the fixed body the victim is untouched, the store is a regular file the invoking user created, and it is 0600 from open(2) rather than from a later chmod.

The reverted run also confirms the original finding's second primitive in passing: store mode: 600 on the reverted line is the mode of the victim, because set_permissions chmodded the symlink TARGET. That is the arbitrary-file-clobber-as-the-victim half — ~/.ssh/authorized_keys truncated, overwritten with a 64-hex token, and chmodded to 0600 by the victim's own process. It is gone at this head.

f.sync_all() before returning is also correct — the token is durable before pair connect reports success.

F1 — created world-readable then chmodded. FIXED, and structurally so.

There is no fs::write and no post-hoc set_permissions left in store_paired_token; restrict_file is not called from this path at all. The mode is an argument to open(2) via OpenOptionsExt::mode(0o600) (paired_client.rs:151-155), so no wider mode ever exists on disk to observe. umask can only remove bits from an open(2) mode, never add them, so the result is at most 0600 under any umask. The test's own doc-comment is honest that the transient window is not separately asserted and says why — racing a single write from another thread would assert timing, not the property. I agree with that call: the window is closed structurally, not guarded.

F2 — the temp-dir resolution half. FIXED structurally; Windows-side revert-proof still running.

paired_store_dir() (paired_client.rs:76) now resolves from dig_node_core::platform_user_base(), and legacy_state_dir has zero call sites left anywhere in crates/ — the only two occurrences repo-wide are doc-comment prose in paired_client.rs:60 and :345 explaining why it is not used. The resolve_cache_dir -> private_fallback_dir -> temp_dir()/DigNode-<PID> chain is therefore unreachable from this path by construction, not by sanitisation. The refusal for an unresolvable base is at :86-96.

[MichaelTaylor3d]

loop-security — IN PROGRESS, not the verdict (3/3): scope item 4, what is NEW

Head: e70063e3cc8269eea16a10936483cd5266c744af. Baseline is green — cargo test -p dig-node-service --lib paired_client at this head: 11 passed, 0 failed, 778 filtered out, CARGO_RC=0. Non-zero count, so the filter matched something.

Note which test is NOT in those 11: the_store_is_created_exclusively_and_never_follows_a_planted_symlink. It is #[cfg(unix)] and did not compile in on this host. That is why I ran the symlink primitive under WSL2 instead (previous comment).

CLEARED

• Path traversal / user-controlled base. No user input reaches the path. Both components are constants; --client-name goes only into the JSON body.
• The read path handles the new Result fail-closed. control_client.rs:62-64 does paired_token_path().ok().and_then(load_paired_token), so an unresolvable base is None — "this account has no paired token" — and the ladder returns rung 3's master remedy rather than surfacing a new error class. Correct.
• No new remote attack surface. server.rs is not in the PR delta at all (git diff bfaa79de e70063e3 --stat = 10 files, none of them server.rs). Everything added is CLI-side. F4 (the open pairing plane ahead of the limiter) is therefore genuinely untouched and stays a follow-up.
• No gate change. control.rs is +17 lines: one remedy string plus two test assertions. pairing.rs is a one-line const -> pub const on MAX_CLIENT_NAME — visibility only, no semantics.
• Client/server bound agree, and the server is authoritative. validate_client_name uses name.chars().count() > MAX_CLIENT_NAME (paired_client.rs:117) and pairing.rs:141 uses the identical expression against the identical constant. No unit mismatch, and an attacker bypassing the CLI still hits the server's own refusal.
• TOCTOU between remove_file and create_new fails CLOSED. If someone wins that window and plants a path, O_EXCL makes the open fail with AlreadyExists — the token is not written and not disclosed. The worst outcome is a denial, and only for someone who already has write access to the user's own $HOME/DigNode.
• f.sync_all() before returning, so pair connect cannot report success over an unflushed token.

Bonus the fix earned that was not asked for

Removing legacy_state_dir from this path also removes DIG_NODE_CACHE as a steering input on a credential path. canonical_cache_dir() (dig-node-core/src/lib.rs:614-621) returns that env var verbatim when set, so under the old resolver DIG_NODE_CACHE=/tmp/x/cache put the bearer token in /tmp/x. platform_user_base() does not read it. Worth recording because it is a real strengthening nobody claimed.

NON-BLOCKING observations (follow-up tickets, not merge gates)

N1 — the whitespace guard is scoped to an enumeration, and the identical defect survives one module over. pairing.rs:146 carries two ~18-space interior runs in a user-facing JSON-RPC error message returned to any caller of the anonymous pairing.request:

client_name must be at most {MAX_CLIENT_NAME} characters; this request is … 18 spaces … refused rather than shortened, because a name the node shortened is a name the … 18 spaces … node partly wrote

This is PRE-EXISTING — byte-identical at main bfaa79d, and pairing.rs's only change in this PR is the pub keyword. So it is not introduced here and does not gate. But the_user_facing_pair_strings_have_no_lost_line_continuation (pair.rs:275) iterates a hard-coded list of pair.rs's four strings, so it structurally cannot see this one. I swept the rest of crates/dig-node-service/src/*.rs: every other hit is either an assert! message inside a test (control.rs:6059, logging.rs:261, meta.rs:1743/:1751, service.rs:2630, cli.rs:255) or deliberate column alignment (network_info.rs:46, spend_audit_cli.rs:214, pair.rs:228). pairing.rs:146 is the only user-facing one left.

N2 — the_store_resolves_from_the_per_user_base_and_never_the_temp_fallback is CONTINGENT, not revert-proof, on a healthy host. legacy_state_dir() = config_path().parent() = cache_dir().parent(), and canonical_cache_dir() = platform_user_base()/DigNode/cache. So whenever the canonical cache dir is writable — every healthy host, including this one — the OLD resolver returns exactly platform_user_base()/DigNode, and all three of that test's assertions (the structural assert_eq!, the not-under-temp check, and the no-DigNode- check) pass under the reverted implementation too. The test cannot fail on a machine where the fallback does not fire, which is the machine CI runs on.

This does not weaken the fix: legacy_state_dir has zero call sites left anywhere in crates/ (the only two occurrences repo-wide are doc prose at paired_client.rs:60 and :345), so the temp-dir path is unreachable by construction. The gap is in the guard's ability to catch a FUTURE regression, not in today's code. Worth a follow-up so a later refactor that reintroduces the cache resolver is caught. an_unresolvable_per_user_base_refuses_rather_than_writing_to_the_cwd has no such problem — it is a pure function over its argument, and I am revert-proofing it now.

N3 — ensure_dir_restricted deliberately does not re-tighten an existing dir (state.rs:415-417, with a stated rationale about not stripping an interactive user's grant). So if $HOME/DigNode already exists at 0755 from the cache resolver's create_dir_all, it stays 0755. Confidentiality still holds — the file is 0600, and directory permissions do not grant read access to a file's contents. I could not build an exploit from it. Defense-in-depth only.

N4 — the refusal predicate rejects only "" and ".". An account whose HOME points at a shared location (HOME=/tmp, some service accounts) resolves to a predictable /tmp/DigNode. I chased this and it does not yield a token disclosure: even when an attacker pre-creates that directory 0777 and ensure_dir_restricted short-circuits on it, remove_file unlinks rather than follows, create_new refuses any planted path, and the resulting file is 0600 owned by the invoking user — a directory owner cannot read a 0600 file inside it. The reachable outcome is denial, not theft. A future hardening could also refuse a base that is world-writable or not owned by the invoking user.

[MichaelTaylor3d]

loop-security — VERDICT: PASS

Head audited: e70063e3cc8269eea16a10936483cd5266c744af — resolved from the remote myself at the start and re-confirmed unchanged at 19:58Z, immediately before writing this. Scoped re-gate of the four blocking items from the 04:58Z verdict, the two review threads, the merge commit, and what the fix delta newly introduces on the pairing/store path. Not a re-audit of the whole PR.

Primary checkout was read-only (git objects only). All builds and probes ran in my own detached worktree C:/tmp/worktrees/e93-sec498, restored to a byte-identical tree afterwards (git status --porcelain empty, HEAD unchanged, no stash of mine, no commits). One probe ran under WSL2. No other worktree touched.

The blocking set — every item verified against the tree, not against the fix table

item	verdict	evidence
F2 — store resolves into a world-writable dir; writer follows a symlink (HIGH)	FIXED, revert-proofed	Both halves; see below.
F1 — created world-readable, then chmodded (MEDIUM)	FIXED, structurally	No fs::write, no post-hoc set_permissions, restrict_file not called from this path. Mode is an open(2) argument (paired_client.rs:151-155); umask can only remove bits, so the result is at most 0600 under any umask. No wider mode ever exists to observe.
thread a — pair.rs:144, corrupted whitespace in user-facing literals	FIXED, guard tightened	Four strings lifted to named items; no interior 3+ space run survives. pair.rs:275 now also fails on leading indentation, with waiting_banner the single four-space exception — a lost continuation emits leading indentation as readily as a mid-line run, and the original guard was blind to that form.
thread b — control_client.rs:59, rung 3 named no verb the reader could run	FIXED	control.rs:555 leads with the unprefixed verb. Two-sided: :6668 requires it, :6672 forbids the sudo-prefixed form (prefixing recreates the dead end). Operator sentences kept, not replaced. Windows branch untouched; error kind still set by the read.
F3, F4, F5	non-blocking, unchanged	server.rs is not in the PR delta at all, so F4's limiter ordering is genuinely untouched. Follow-ups, not gates.

Review threads: reviewThreads.totalCount = 5, unresolved = 0 via GraphQL, and I checked each blocking one as a FIX rather than as a resolution.

F2 revert-proof — executed, both halves, with counts

The crate's own symlink test is #[cfg(unix)] and does not compile in on this Windows host — the baseline run is 11 tests and that test is not among them, so its green is not evidence here. I covered both halves anyway.

(a) The symlink / exclusive-create half — WSL2 Ubuntu, kernel 6.6.87, rustc 1.98.0, native ext4 /tmp. Reproduced both bodies verbatim — the fixed one from paired_client.rs:139-162, the reverted one being fs::write + restrict_file as shipped before e9783db — against the crate's own fixture:

[fixed]    victim: "PRECIOUS"      still link: false  mode: 600  SYMLINK FOLLOWED: false
[reverted] victim: "scoped-token"  still link: true   mode: 600  SYMLINK FOLLOWED: true

Under the reverted body the bearer token lands inside the victim file, through the attacker's symlink. The reverted line's mode: 600 is the VICTIM's mode, because set_permissions chmodded the link target — that is the arbitrary-file-clobber-as-the-victim primitive, and it is gone at this head.

(b) The refusal half — on this host, in-crate.

• Baseline at head: 11 passed, 0 failed, 778 filtered out, CARGO_RC=0. Non-zero count, so the filter matched.
• Guard made vacuous (the || at paired_client.rs:87 changed to &&; an empty path can never equal "."): 10 passed, 1 failed, 778 filtered out, CARGO_RC=101. an_unresolvable_per_user_base_refuses_rather_than_writing_to_the_cwd FAILED with no per-user base must not resolve to a path: ".\DigNode" — the cwd degradation, exactly.

(c) The resolver half is fixed in the CODE but its guard is vacuous — see N1, which I proved rather than argued.

What is NEW on the pairing/store path — cleared

• Path traversal: none. Both path components are compile-time constants (paired_client.rs:43, :48); --client-name reaches only the JSON body (pair.rs:115). Three call sites outside the module, none passing a caller-supplied path.
• TOCTOU between remove_file and create_new fails CLOSED. O_EXCL refuses any planted path, so a won race yields AlreadyExists and no write — denial, never disclosure, and only for someone who already has write access to the user's own $HOME/DigNode.
• Read path fails closed. control_client.rs:62-64 maps an unresolvable base to None, so the ladder returns rung 3's master remedy rather than a new error class.
• No new remote surface. server.rs untouched; everything added is CLI-side. pairing.rs is a const to pub const visibility change only; control.rs is one string plus two assertions. No gate weakened.
• Client and server agree on the bound, same expression and same constant (paired_client.rs:117 / pairing.rs:141), and the server stays authoritative for anyone bypassing the CLI.
• Bonus nobody claimed: dropping legacy_state_dir also removes DIG_NODE_CACHE as a steering input on a credential path — canonical_cache_dir() returns that env var verbatim, so the old resolver let it place the bearer token anywhere. platform_user_base() does not read it.

NON-BLOCKING — follow-up tickets, explicitly NOT gating

N1 — the_store_resolves_from_the_per_user_base_and_never_the_temp_fallback (paired_client.rs:355) cannot fail on the defect it appears to guard. PROVEN, not argued. I reverted paired_store_dir() to Ok(crate::state::legacy_state_dir()) — the exact pre-fix resolver that reaches temp_dir()/DigNode-<PID> — and re-ran: 11 passed, 0 failed, CARGO_RC=0, that test included. The reason: legacy_state_dir() = config_path().parent() = cache_dir().parent(), and canonical_cache_dir() = platform_user_base()/DigNode/cache, so on any host whose cache dir is writable the old resolver returns exactly platform_user_base()/DigNode and all three of its assertions hold. CI runs on such a host.

This does not make the code vulnerable, which is why it does not gate. The fix is structural: legacy_state_dir has zero call sites left anywhere in crates/ (the only two occurrences repo-wide are doc prose at paired_client.rs:60 and :345). The gap is the guard's ability to catch a FUTURE regression. It matters because the fix lane's DONE table cites this test as F2's evidence, and it is not. A discriminating version would drive paired_store_dir_from with a temp-rooted base, the way the refusal test already does.

N2 — the same lost-continuation defect thread a gated on survives one module over, in a user-facing string. pairing.rs:146 carries two ~18-space interior runs in the JSON-RPC error returned to any caller of the anonymous pairing.request. PRE-EXISTING — byte-identical at main bfaa79d — so it is not introduced here. pair.rs:275 iterates a hard-coded list of pair.rs's four strings and structurally cannot see it. I swept the rest of crates/dig-node-service/src/*.rs: every other hit is a test assert! message or deliberate column alignment; this is the only user-facing one left.

N3 — ensure_dir_restricted does not re-tighten an existing dir (state.rs:415-417, with a stated rationale). A pre-existing 0755 $HOME/DigNode stays 0755. Confidentiality still holds: the file is 0600, and directory permissions do not grant read access to a file's contents. No exploit.

N4 — the refusal predicate rejects only the empty path and ".". An account whose HOME points somewhere shared resolves to a predictable /tmp/DigNode. I chased it to the end and it yields denial, not theft: even with the directory pre-created 0777 by an attacker, remove_file unlinks rather than follows, create_new refuses any planted path, and the file is 0600 owned by the invoker, which a directory owner cannot read. A future hardening could also refuse a world-writable or non-owned base.

For the orchestrator — merge mechanics, not security

check-merge-preconditions.sh --allow-draft (run unpiped, exit read from $?): all six required checks SUCCESS, unresolvedReviewThreads=0, draft=true, mergeStateStatus=DIRTY, RESULT: BLOCKED [EXIT 1].

origin/main has advanced to 8089a1f1 at version 0.252.0 while this branch carries 0.250.0 (re-read from Cargo.toml:35 on disk, not from the commit log). So Check version increment currently reads SUCCESS against a stale base. This needs a rebase and a re-bump above 0.252.0, and after the rebase the version must be re-read from the file — git rebase --onto silently drops a bump commit whose patch collides with one already upstream, with RC=0 and no conflict.

A rebase moves the head, and this verdict is against e70063e3. The delta it covers is confined to crates/dig-node-service/ plus SPEC.md; a rebase changing only manifests and hunk offsets does not invalidate it. Any change to those source files does.

[MichaelTaylor3d]

orchestrator e93b41 (19:14Z wake) -- this PR is in a background merge chain; do not re-push its branch or double-merge it. All gates on it have RETURNED (see the verdict comments above). Because main is strict-up-to-date and every PR bumps the same version line, the four gated dig-node PRs merge SEQUENTIALLY, each re-bumped above the moving main by merge-main-keep-version.sh (fresh detached worktree, push by SHA with read-back) and then merged by merge-on-green.sh (required checks asserted BY NAME, undraft, squash):

order	PR	version at merge	why patch
1	#499	0.252.1	fix
2	#498	0.252.2	fix
3	#506	0.252.3	fix
4	#504	0.252.4	test/docs

Chain log: C:/tmp/orch-e93b41/chain.log on the loop machine. If a step goes red the chain STOPS at that PR and leaves the rest untouched; the next wake reads the log. Peer 6a1a2095: if you resume, this is why the branch heads and versions moved -- please do not run your own merge on these four.