Peering card: allow replacing the outbound key in place (symmetric key rotation) #236

New issue

Closed

opened 2026-08-14 17:46:05 +00:00 by Cordy · 1 comment

Cordy commented

2026-08-14 17:46:05 +00:00

Owner

Found during the 2026-08-14 A↔B dogfood.

The relationship card (#150) manages the inbound key fully — issue, revoke, re-issue — but there is no equivalent for the outbound key: the Peer.Key, i.e. the credential the other admin issued you and that you present to reach them. If that key ever changes — the counterpart rotates/re-issues their inbound key, or the original paste was wrong — the card offers no way to update it. The only recovery is Remove the whole peer and re-register, which also drops the URL, the send/receive allow-lists, and your own issued inbound-key state.

Concretely, right now: files-bao re-issued its "files" inbound key, so files' "bao" peer holds a stale outbound key — and with no "replace key" affordance, the only path back is remove + full re-add + re-exchange.

Proposal: add an inline Replace key action on the outbound side of the card — a field to paste the new key-they-sent-you — PATCHing just Key via the existing PATCH /api/v1/admin/peering/peers/{name} (add key to the partial-update handler; validate the CAIRN-PEER1. prefix as registration does). This makes key handling symmetric:

inbound: issue / revoke / re-issue (already present),
outbound: replace-in-place (new).

Theme with #235 (editable URL): the card should let you fix or rotate any non-structural field of a standing relationship in place — URL and outbound key — so a routine change never forces remove + re-register + re-key. Together, #235 + this make peer maintenance non-destructive; the only thing that should ever require a real re-exchange is genuinely losing the key material.

Refs: #150, #176, #235.

Found during the 2026-08-14 A↔B dogfood. The relationship card (#150) manages the **inbound** key fully — issue, revoke, re-issue — but there is **no equivalent for the outbound key**: the `Peer.Key`, i.e. the credential the *other* admin issued you and that you present to reach them. If that key ever changes — the counterpart rotates/re-issues their inbound key, or the original paste was wrong — the card offers no way to update it. The only recovery is **Remove the whole peer and re-register**, which also drops the URL, the send/receive allow-lists, and your own issued inbound-key state. Concretely, right now: files-bao re-issued its "files" inbound key, so files' "bao" peer holds a stale outbound key — and with no "replace key" affordance, the only path back is remove + full re-add + re-exchange. **Proposal:** add an inline **Replace key** action on the outbound side of the card — a field to paste the new key-they-sent-you — PATCHing just `Key` via the existing `PATCH /api/v1/admin/peering/peers/{name}` (add `key` to the partial-update handler; validate the `CAIRN-PEER1.` prefix as registration does). This makes key handling symmetric: - inbound: issue / revoke / re-issue (already present), - outbound: **replace-in-place** (new). **Theme with #235 (editable URL):** the card should let you fix or rotate any non-structural field of a *standing* relationship in place — URL and outbound key — so a routine change never forces remove + re-register + re-key. Together, #235 + this make peer maintenance non-destructive; the only thing that should ever require a real re-exchange is genuinely losing the key material. Refs: #150, #176, #235.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-08-15 13:18:40 +00:00

Cordy referenced this issue

2026-08-15 13:41:24 +00:00

Peering dogfood: second instance on k3s + live A↔B e2e #106

Cordy referenced this issue from a commit

2026-08-15 14:00:07 +00:00

ci: ship-2356 one-shot (#235 #236)

forgejo-actions referenced this issue from a commit

2026-08-15 14:12:08 +00:00

#235 #236: edit peer URL and replace outbound key on the card (v0.6.24)

Cordy referenced this issue from a pull request that will close it,

2026-08-15 14:16:04 +00:00

#235 #236: edit peer URL and replace outbound key on the peering card (v0.6.24) #240

Cordy referenced this issue from a commit

2026-08-15 14:18:20 +00:00

#235 #236: edit peer URL and replace outbound key on the peering card (v0.6.24) (#240)

Cordy closed this issue

2026-08-15 14:18:20 +00:00

Cordy commented

2026-08-15 14:30:28 +00:00

Author

Owner

Shipped in v0.6.24 (PR #240, merged). The card's actions row now has a Replace key affordance mirroring the existing inbound issue/revoke — it opens a CAIRN-PEER1… input + Save/Cancel and PATCHes just key (the key the peer issued us, i.e. the outbound side). The key is validated for the CAIRN-PEER1. prefix; the URL is left untouched. This closes the asymmetry noted in the #106 dogfood where the inbound key could be re-issued but the outbound key couldn't be replaced without a full Remove + re-register + re-exchange.

Live on both dogfood instances on v0.6.24, both pods 1/1. Closing.

Shipped in v0.6.24 (PR #240, merged). The card's actions row now has a **Replace key** affordance mirroring the existing inbound issue/revoke — it opens a `CAIRN-PEER1…` input + Save/Cancel and PATCHes just `key` (the key the *peer* issued us, i.e. the outbound side). The key is validated for the `CAIRN-PEER1.` prefix; the URL is left untouched. This closes the asymmetry noted in the #106 dogfood where the inbound key could be re-issued but the outbound key couldn't be replaced without a full Remove + re-register + re-exchange. Live on both dogfood instances on v0.6.24, both pods 1/1. Closing.

Cordy referenced this issue

2026-08-15 14:43:07 +00:00

Peering card: show the outbound key as its own row with a fingerprint (symmetric with inbound) #241

Cordy referenced this issue

2026-08-15 14:54:51 +00:00

#241: outbound key gets its own row + fingerprint on the peering card (v0.6.25) #242