A stock Linux .deb service resolves its wallet seed to ./DigWallet/seed.bin, relative to the service cwd

[MichaelTaylor3d]

What happens

On a stock Linux .deb install, the node's wallet seed resolves to ./DigWallet/seed.bin —
relative to the service's working directory — rather than to any per-user or machine location.

dig_wallet::autoseed::user_base() (crates/dig-wallet/src/autoseed.rs:110-120) resolves
LOCALAPPDATA -> HOME -> ".". The shipped unit
packaging/linux/systemd/net.dignetwork.dig-node.service sets neither: it has no User=, no
Group= and no HOME=, its only Environment= line is DIG_NODE_RUN_CONTEXT=service, and it
carries ProtectHome=true. So both lookups miss and the chain falls through to ".".

Under ProtectSystem=full that path is very likely unwritable, so the mint fails and the node comes
up wallet-less.

Why it matters

This is the shape of dig_ecosystem#1928, where a stock .deb came up with no identity and never
joined the network — a defect nobody saw because each individual manifest and unit looked
reasonable.

It also means the two resolvers of "the per-user base" disagree on a stock Linux install with no
operator override at all: dig_node_core::platform_user_base() returns /root, because
directories::BaseDirs' Linux home_dir falls back to getpwuid_r when $HOME is unset
(dirs-sys-0.5.0/src/lib.rs:33-47), while the wallet returns ".". dig-node#392 makes that
divergence audible; it does not make it correct. This ticket is the correctness half.

How this was found

While gating dig-node#392 (PR #489). The #392 fix originally refused to mint under a divergent root,
which would have turned this latent misplacement into a hard "no wallet on any stock Linux install".
The gate caught it and the predicate was narrowed to fire only on a deliberate LOCALAPPDATA
override — so #392 no longer depends on this being fixed, and this is not a release blocker for it.

Scope

• Decide where a Linux service's wallet seed SHOULD live. The machine state dir the service already
  resolves and hardens (/var/lib/dig-node, crate::state) is the obvious candidate and is already
  the answer for the identity seed and cache via state::service_data_dir_overrides — the wallet
  seed was simply never included in that anchoring.
• Do not silently relocate an existing seed. A host that already minted one at some path must
  keep opening it; the same reasoning that kept dig-node#392 from re-rooting the wallet applies here
  in full. Whatever the fix, an existing wallet must not be orphaned.
• "." as a final fallback for a key file is worth reconsidering on its own. A relative path means
  the seed location depends on the working directory of whoever started the process.

Related, and worth its own line

CI never runs on Windows. .github/workflows/ci.yml is ubuntu-latest on all four jobs
(Release-script tests, Rustfmt, Clippy, Test + coverage), so no Windows-specific path behaviour in
this crate is exercised anywhere in CI. That was raised by the #392 security gate, which could not
reproduce a Windows-only false-split precisely because nothing runs there. The #392 fix works around
it by making the platform-dependent comparison a pure function with the case-sensitivity as a
parameter, so both arms run on the Linux runner — but that is a workaround for one function, not
coverage.

Parent: #392

[MichaelTaylor3d]

Premise verified, and the predicted outcome is wrong in the dangerous direction

Measured 2026-09-01 against systemd.exec(5) and the shipped files, not inferred. Working PR: #499 (draft).

The three systemd facts, from the man page

1. $HOME is UNSET. systemd.exec(5): "$USER is set unconditionally, while $HOME, $LOGNAME, and $SHELL are only set for the units that have User= set and SetLoginEnvironment= unset or set to true." And SetLoginEnvironment= "defaults to true if User=, DynamicUser= or PAMName= are set, false otherwise." packaging/linux/systemd/net.dignetwork.dig-node.service sets none of the four.

2. The cwd is /. The unit sets no WorkingDirectory=, and "If not set, defaults to the root directory when systemd is running as a system instance."

3. / is WRITABLE, and the service runs as root. ProtectSystem=full mounts /usr, /boot, /efi and /etc read-only. Only strict mounts / read-only. The unit sets no User=.

The resolved path

dig_wallet::seed_path() (crates/dig-wallet/src/lib.rs:166-170) resolves LOCALAPPDATA -> HOME -> ".". Both lookups miss, so base is "." and cwd is /.

The seed lands at /DigWallet/seed.bin — the filesystem root — and the write succeeds. The device key resolves through the identical chain in autoseed::user_base() (crates/dig-wallet/src/autoseed.rs:110-120) to /DigNode/device/device.key. Both come from the same broken base, so they stay consistent and the wallet does open.

Which of the three cases

Case 1: created at the wrong path, silently. Not case 2.

The ticket predicted "under ProtectSystem=full that path is very likely unwritable, so the mint fails and the node comes up wallet-less." That is wrong, and wrong in the direction that costs more: an unwritable path produces a visible failure somebody eventually investigates. A successful write to /DigWallet produces a working node that nobody looks at. This is also why the defect survived — every install has a functioning wallet, just not where anyone would look for it.

There is a second, distinct consequence with the case-2 shape, worth its own line: an operator running dign interactively does have $HOME, so the CLI resolves a different wallet from the service's. The node's operator wallet holds real $DIG for mirror-coin collateral, so the CLI reports on an empty wallet while the funded one sits at the root.

One correction to the ticket's supporting detail

dig_node_core::platform_user_base() does not exist on origin/main — it arrives with #392 / PR #489, still open. The two-resolvers-disagree observation is therefore about the post-#489 tree, not today's. It does not change the diagnosis above, which rests only on seed_path() and the unit file.

Fix shape being built on #499

• Override the base, not the wallet directory, through one resolver shared by seed_path() and autoseed::user_base(). autoseed.rs's module docs call the device-key-as-sibling-never-child placement "the entire partial-exfiltration boundary"; overriding the base preserves it structurally, whereas a wallet-dir override or two separate overrides let the pair drift apart and re-create exactly that failure.
• Anchor it for a service run via the existing state::service_data_dir_overrides (crates/dig-node-service/src/state.rs:199) that already anchors identity and cache. /var/lib/dig-node is pre-created 0700 root:root by the .deb postinst.
• Do not orphan an existing wallet. The anchor is adopted only when no wallet is present at the legacy path; if one is, the legacy path keeps being opened and a warning names the path. Key material is never moved automatically. A host already running the buggy build has a funded operator wallet at /DigWallet, and silently switching it to a fresh empty one would convert this bug into a money loss.

[MichaelTaylor3d]

Fix pushed on loop/491-wallet-seed-path at 48e138f; draft PR #499 body carries the full write-up.

Measured outcome: this is case 1 - the seed was CREATED at /DigWallet/seed.bin and the write SUCCEEDED (root service, ProtectSystem=full leaves / writable). The node came up with a working wallet at the filesystem root. The ticket's guess that the path is unwritable and the node comes up wallet-less is wrong.

Shape: one DIG_WALLET_BASE override of the BASE both roots hang off, anchored at the machine state dir for a service run, adopted ONLY when no wallet exists at the legacy resolved path (fail-closed on undeterminable presence). No key material moved.

Red-then-green, counts in the PR body. Still DRAFT - gate round not run.