A node can no longer check in as another node or advertise addresses it wasn't asked for

Two gaps let a node act on behalf of other nodes. A credential issued for one node could check in under another node’s ID. Separately, nodes stored node addresses that anyone who could reach them sent unasked, and could pass those addresses on. Both are now closed.

No incident of this has occurred. This is a proactive security fix.

Check-ins under another node’s ID are refused

From 19 October, the control plane refuses a registration or check-in whose credential wasn’t issued for the node it names. Nothing changes for the named node: it isn’t marked blocked, and nothing is recorded against it.

Nodes keep only answers to their own questions

From v0.0.127, a node takes a reply about where content is held only when it answers a question that node asked. The reply has to come from the address the question went to, about the content asked, within 30 seconds, and it is accepted once. Anything else, including announcements nobody asked for, is ignored.

Other POPs never supply an address

A reply from another POP can still say that a node there holds some content, but any address in it is left out. A node never hands out an address it learned that way, and a reply never changes a record the node got from the control plane.

What changes for you

• Site owners: nothing.
• Operators running under their own node ID: nothing. Check-ins carry on as before.
• Operators running under another ID: a node running under an ID other than the one its key was issued for, for example with NODE_ID set by hand, is refused on every check-in until it runs under its own ID. Its request logs are kept until its buffer of 10,000 entries fills. The node owner entry covers what else changed for nodes running under an overridden ID.

What you need to do

If you’ve set NODE_ID by hand, remove it so your node runs under the ID it enrolled with. Update your node to v0.0.127 or later.