no supported way to install without first joining the public network — the node auto-starts before configuration

Task

The package auto-starts the node on stock config, so there is a window between apt install and the operator's configuration landing during which the node is on the public network. Observed: node B connected to a stranger (62ecc368...) before the config drop-in applied.

Judgement: intended behaviour, with a real and bounded side effect — NOT a security defect

A node with no configuration finding peers is the seed-host design (https://github.com/DIG-Network/dig_ecosystem/issues/923), and it is what makes a plain install work for an ordinary user. Nothing is exposed in the window: the node holds no capsules, serves no content it did not just generate, and presents a fresh identity. There is no leak of operator data.

What IS real, and why this is filed rather than dismissed:

The announcement outlives the window. A node that joins the public DHT and then leaves for a private network leaves a provider/peer record with a TTL behind it. Other nodes then dial an address that no longer serves them.
It silently defeats intended isolation. An operator standing up an isolated test network has no supported way to install without first joining the public one. That is exactly what happened on the three-machine run behind https://github.com/DIG-Network/dig_ecosystem/issues/3128, and it made "is this peer part of my test?" ambiguous during diagnosis.
The identity is minted before the operator chooses one. A node configured afterwards with a different identity has already advertised the first.

Severity: low, kind:maintenance. It costs diagnostic clarity and leaves stale records; it does not expose the host or its data.

Context

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3128
Related: https://github.com/DIG-Network/dig_ecosystem/issues/923 (a node with no config should find peers — the behaviour this ticket does NOT propose removing)

Scope

Give the install a supported "configure before joining" path — the smallest thing that works. A /etc/dig-node/no-autostart marker the unit checks, or shipping the unit disabled with the postinst enabling it only when no drop-in is pending, are both adequate. Do not change the default for an ordinary user: an unconfigured node must still find peers.

Evidence bar

An install with the marker present leaves the node not-started and connected to nobody; an install without it behaves exactly as today.

Lane open. Branch loop/316-317-deb-dign-isolation, draft PR #359 (batched with the sibling ticket — one branch, one PR, closes both).

Worktree: worktrees/dn-316-317. Next action: TDD red — a scripts/tests/deb-contents.test.sh that builds a .deb and asserts dpkg-deb -c lists /usr/bin/dign and that the postinst honours a configure-before-joining marker.

Fixed and proven on a real Ubuntu 24.04 host with systemd. Branch loop/316-317-deb-dign-isolation, HEAD 8a93ef2, PR #359 (draft; gate round pending).

Taking the ticket's own framing: the default is not changed, an entry point is added.

What ships

postinst honours /etc/dig-node/no-autostart. If it exists at configure time the unit is installed and daemon-reloaded but not enabled and not started, and the install prints how to start it. The marker is read, never written, by the package.
A new operator-owned conffile /etc/dig-node/dig-node.env, read by the unit via EnvironmentFile=-. Every line is commented out, so an untouched file changes nothing.
daemon-reload still runs under the marker — otherwise the operator gets a package that registered nothing and cannot systemctl start afterwards.

Measured

Marker present at install:

Setting up dig-node (0.149.0) ...
dig-node: /etc/dig-node/no-autostart present — the service is installed but NOT started.
dig-node: configure /etc/dig-node/dig-node.env, then: systemctl enable --now net.dignetwork.dig-node.service

is-enabled: disabled     is-active: inactive     LoadState=loaded
(no node process — it did not start, so it never joined)

Control — the same package, no marker (this is the dig_ecosystem#923 default, and it is untouched):

is-enabled: enabled      is-active: active

For contrast, the journal of that default-start run shows exactly the window this ticket describes: dig_nat::relay: relay reservation established connected_peers=5.

Then the isolated node starts and serves. With DIG_BOOTSTRAP_PEERS=off / DIG_RELAY_URL=off in the env file, read back from the running process rather than from the file:

$ tr '\0' '\n' < /proc/1036/environ | grep ^DIG_
DIG_NODE_RUN_CONTEXT=service
DIG_BOOTSTRAP_PEERS=off
DIG_RELAY_URL=off

$ dign info --json
{"ok":true,...,"running":true,"addr":"127.0.0.1:9778",...}

$ dign peers --json
{..."relay":{"url":"off","reserved":false,"peer_count":0},
 "connected_peers":0,"known_peers":0,"peers":[],...}

Listening sockets include [::1]:9778 alongside the v4 ones, so the dual-stack bind is intact.

off, not empty — and this is the load-bearing detail for anyone staging an isolated fleet. #312 made set-but-empty mean "none", so both spellings are correct to the node. They are not equally durable in transit: on Windows an empty environment variable is DELETED rather than emptied, so it arrives unset and falls back to the public compiled-in anchor. That failure is silent and inverts the experiment — the "isolated" node reaches production and the run passes for the wrong reason. The shipped env file, SPEC.md §Environment and the postinst comment all say off.

Adjacent, deliberately not touched: dig-node#526 (dig-node install prefers user-level systemd when run as root). The .deb writes the system unit directly and never calls dig-node install, so this diff neither fixes nor worsens it.

One honest limitation, logged not ticketed: the node still performs Chia DNS-introducer lookups (seeder.dexie.space etc.) — that is the Chia light-client leg, which these two knobs do not govern. On a genuinely network-isolated host they simply time out. Not a regression and not in scope here.

Resume-ready: branch loop/316-317-deb-dign-isolation, HEAD 8a93ef2, PR #359 (draft, awaiting its gate round).

Done — packaging fix, scripts/tests/deb-contents.test.sh (green in CI, log confirms it RAN rather than skipped), SPEC.md + README.md, version 0.151.1 → 0.152.0 with Cargo.lock re-locked, real-host acceptance on Ubuntu 24.04, seven revert-proofs. Companion docs PR: DIG-Network/docs.dig.net#83.

CI: both build .deb jobs (amd64 + arm64) pass, plus Clippy, Rustfmt, CodeQL, commitlint, version-increment and the service-smoke matrix. Zero failures.

Next action: dispatch the gate round over the combined diff, then undraft and squash-merge. Gate tier: one correctness gate — the diff edits no Rust symbol (shell, systemd unit, a new conffile, a new shell test, docs, version), so the blast radius is the package layout, not the node's behaviour.

chore(packaging): open the lane for dig-node#316 + #317

fix(packaging): ship dign in the .deb and support configure-before-jo…

fix(packaging): restart the systemd unit on .deb upgrade so the new b…

fix(cli): correct the pairing verb, free the exit code, and test the …

fix(cli): the CLI/service/updater batch — six user-visible dead ends (#…

Navigation Menu

Repository navigation

no supported way to install without first joining the public network — the node auto-starts before configuration #317

Task

Judgement: intended behaviour, with a real and bounded side effect — NOT a security defect

Context

Scope

Evidence bar

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

no supported way to install without first joining the public network — the node auto-starts before configuration #317

Description

Task

Judgement: intended behaviour, with a real and bounded side effect — NOT a security defect

Context

Scope

Evidence bar

Activity

MichaelTaylor3d commented on Aug 25, 2026

MichaelTaylor3d commented on Aug 25, 2026

MichaelTaylor3d commented on Aug 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions