HydraIssues

Defense #5 in the mesh.yaml hardening track. Today the hydraguard runbook warns operators to keep the API service stopped:

API warning: Keep the HydraGuard API service stopped (systemctl stop hydraguard) when not actively enrolling new peers. The auto_apply: true setting causes /api/v1/air/provision to regenerate peer keypairs on every call, breaking existing connections. See issue #64.

Thats a band-aid for a known broken code path, not a fix. As of 2026-05-11 the daemon on the Brussels hub IS running with Auto-apply: enabled per the journal logs — the runbook posture is not actually being followed in production.

Suggested fix

In pkg/api/handlers.go (and wherever /api/v1/air/provision is implemented): make the provision call idempotent. If a peer with the requested ID already exists and has a public key, return the existing config rather than rotating keys. Key regeneration should be an explicit operation (/api/v1/air/{id}/rotate-keys), never a side effect of provision.

Also set auto_apply: false as the default in api.yaml so a fresh install does not arm the footgun.

Verification

• Call /api/v1/air/provision twice for the same peer ID. Second call returns the same config the first did (same public key, same address) — no regeneration, no disruption.
• Default api.yaml template generated by hydraguard hub init has auto_apply: false.
• Update the runbook to remove the keep-API-stopped warning.