fix: spec validation refuses this node's own key as a peer #71
No reviewers
Labels
No labels
accessibility
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Keel-Linux/keel!71
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/overlay-peer-not-this-node"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On keel-web-2 (2026-10-03) the operator entered the node's own public key, shown at the top of confconsole's overlay screen, as a peer, and
keel spec validateaccepted it.validate_overlaynow refuses a peer whosepublic_keyis this node's own. The node's key is the public key of the private key file (private_key.file, else/etc/wireguard/<interface>.key), read withwgkeys.publicexactly askeel network wireguard keyreads it. Because that reads a secret file, the check runs only when secret files are checked (--no-secret-filesskips it, as it skips the key file's mode check). No key file yet means apply will make a fresh key, which no peer can hold, so nothing is read; a file wg cannot read (or no wg where the spec is validated) leaves the check to the converging run.confconsole's overlay screen refuses the same thing before it stages the description (it validates with
--no-secret-files), in Keel-Linux/confconsole's companion PR.keel 0.15.4. Tests:
tests/test_spec_overlay.py::TestNotItsOwnPeer, one of them with the real wg (wireguard-tools is installed in CI).