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.
Task
The package auto-starts the node on stock config, so there is a window between
apt installand 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:
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-autostartmarker the unit checks, or shipping the unitdisabledwith 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.