HydraIssues

hydraguard validate: invariants check exposed as a subcommand + run in apply
open feature Project: hydraguard Reporter: 11 May 2026 19:26

Description

Defense #2 in the mesh.yaml hardening track (defense #1 = auto-backup, shipped in v1.10.8; defense #3 = atomic write, already in place).

Add a single Go function that checks the invariants we already expect implicitly:

- mesh.yaml round-trips through yaml.Unmarshal → yaml.Marshal cleanly (catches malformed YAML edits)
- No duplicate WG tunnel addresses across hub + venues + neckair + air
- No duplicate public keys
- Every venue has either auto-assigned or valid `--lan` CIDR; no overlapping LAN CIDRs (already partially handled by `CheckSubnetOverlap` in pkg/mesh/mesh.go)
- Hub public key in mesh.yaml matches `/etc/wireguard/hub.key`
- Every peer has name + tunnel address + public key

Wire it in two places:

1. `hydraguard validate` subcommand — operator can run pre-commit after any manual mesh.yaml edit.
2. `hydraguard apply` calls the same function before writing `/etc/wireguard/wg0.conf`. Bad state → abort with a clear `which field on which peer is wrong` message.

## Why it matters

We already memorialized one nodes.yaml incident under feedback_never_sed_nodes_yaml.md. mesh.yaml is the same class of problem; right now nothing stops a botched edit from generating a broken wg0.conf and silently knocking out a peer (or all of them) at `apply` time.

## Verification

Unit tests in `pkg/mesh/validate_test.go` covering each invariant, plus an integration test that `apply` aborts when given a hand-crafted invalid mesh.yaml.

Custom Fields

affected_repo
hydraguard
category_tag
hardening
effort
medium
related_to
mesh.yaml hardening track