secrets: client-fallback transport keys (wg-cf) for clientsv DNS standby #254

Merged

ymrtech merged 1 commit from feat/clientsv-dns-fallback-secrets into main

2026-09-15 17:26:11 -06:00

hermes commented

2026-09-15 17:20:05 -06:00

Collaborator

What

Encrypts three new secrets for the clientsv client-fallback transport (wg-cf):

Secret	Purpose
`clientsv-cf-vpn-private`	vpn's private key on the client-fallback link
`clientsv-cf-public-private`	public's private key on the same link
`clientsv-cf-psk`	shared preshared key

Encrypted values only — age recipients unchanged (admin, hermes_agent, giga, mail, public, vpn). Each decrypts to a 44-byte key. No config change; no deploy behaviour change.

Why first

The companion PR ymrtech/nix-config-private#feat/client-dns-standby declares sops.secrets.clientsv-cf-* in the clientsv modules. Once that lands on the private main, its CI bumps this repo's lock and deploys — so these entries must already exist here, otherwise sops-nix activation fails on the hosts.

Merge order: this PR → nix-config-private PR.

Verify

sops -d --extract '["clientsv-cf-vpn-private"]' secrets/secrets.yaml | wc -c   # 44

## What Encrypts three new secrets for the clientsv client-fallback transport (`wg-cf`): | Secret | Purpose | | --- | --- | | `clientsv-cf-vpn-private` | vpn's private key on the client-fallback link | | `clientsv-cf-public-private` | public's private key on the same link | | `clientsv-cf-psk` | shared preshared key | Encrypted values only — age recipients unchanged (admin, hermes_agent, giga, mail, public, vpn). Each decrypts to a 44-byte key. No config change; no deploy behaviour change. ## Why first The companion PR **ymrtech/nix-config-private#feat/client-dns-standby** declares `sops.secrets.clientsv-cf-*` in the clientsv modules. Once that lands on the private main, its CI bumps this repo's lock and deploys — so these entries must already exist here, otherwise sops-nix activation fails on the hosts. Merge order: **this PR → nix-config-private PR.** ## Verify ``` sops -d --extract '["clientsv-cf-vpn-private"]' secrets/secrets.yaml | wc -c # 44 ```

hermes added 1 commit

2026-09-15 17:20:05 -06:00

secrets: client-fallback transport keys (wg-cf) for clientsv DNS standby

NixOS Build Check / Eval giga (scope + liveness + offline fallback) (pull_request) Successful in 2s

Details

NixOS Build Check / Scope changed deployable hosts (pull_request) Successful in 3s

Details

NixOS Build Check / Eval giga natively (authoritative, on giga) (pull_request) Has been skipped

Details

Secret Scan / gitleaks scan (pull_request) Successful in 6s

Details

NixOS Build Check / Build mail closure (on mail) (pull_request) Successful in 11s

Details

NixOS Build Check / Build vpn closure (on vpn) (pull_request) Successful in 18s

Details

NixOS Build Check / Build public closure (on public) (pull_request) Successful in 46s

Details

NixOS Build Check / Alert Hermes on failure (pull_request) Has been skipped

Details

cd80f18c9c

Encrypted values only (age recipients: admin, hermes_agent, giga, mail, public,
vpn). Three entries:
  clientsv-cf-vpn-private   - vpn's wg-cf private key
  clientsv-cf-public-private- public's wg-cf private key
  clientsv-cf-psk           - shared preshared key for the link

Consumed by the private flake's clientsv-vpn.nix (vpn side) and
clientsv-standby.nix (public side) via sops.secrets declarations there.

hermes commented

2026-09-15 17:23:36 -06:00

Author

Collaborator

CI green (eval + secret-scan). This is the first of the two merges: merge this before ymrtech/nix-config-private#16 — the private modules declare sops.secrets.clientsv-cf-*, and the private CI bumps this repo's lock + deploys immediately after that PR lands, so these encrypted entries must already be on main or sops-nix activation fails on public/vpn.

No behaviour change on its own (secrets only).

CI green (eval + secret-scan). This is the **first** of the two merges: **merge this before ymrtech/nix-config-private#16** — the private modules declare `sops.secrets.clientsv-cf-*`, and the private CI bumps this repo's lock + deploys immediately after that PR lands, so these encrypted entries must already be on `main` or sops-nix activation fails on public/vpn. No behaviour change on its own (secrets only).