carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

| Round-3 finding | Disposition at 7dcdf31e | |---|---| | A3-1 — Failed authentication resets the forwarding budget | Closed at design level. Version 2 authenticates the count and destination region; rejected credentials cannot trigger further forwarding. The newly specified key-rotation contract needs correction below. | | A3-2 — Removing public addresses breaks old readers | Partially closed. Stage 1 preserves legacy publication and adds compatible receivers. The stage-2 gate does not yet prevent a return to incompatible binaries. | | A3-3 — Stalled refresh worker remains healthy | Closed. Completed failures count as progress. The existing two-minute context covers the entire refresh attempt (homemap.go:849), so five minutes accommodates the timeout and 30-second poll interval. | | Stale summaries | Closed. The first-build exception and zone-B deferral are corrected. |

  1. P2 — Stage 2 needs a forwarding-specific release floor, not just a capability advertisement. Spec:228

A box can publish fwd_protocol: 2, satisfy the console’s check, then return to a pre-forwarding release through rollback or recovery. That release can still satisfy the existing claim/HA floor: nothing here raises it to the release introducing version 2. Existing recovery explicitly restores carlos.prev, subject to its activation guards (systemapply.go:1604).

After stage 2, that box cannot authenticate the new credentials or perform the required second hop. After stage 3, it also discards peers whose publication lacks eip. Waiting one release cycle does not prohibit this regression.

Require every participating box to report an armed floor covering the forwarding release before enabling stage 2, including protection of rollback and boot recovery. Test activation racing with recovery to an incompatible .prev.

  1. P2 — “Current and previous” conflicts with the existing mesh-key rotation protocol. Spec:224

The current implementation loads current and .next, and immediately prefers .next for signing (mesh.go:167). It neither loads nor retains a previous-key slot; successful refreshes replace the cached pair (homemap.go:812).

During a rotation, an existing signer therefore uses the successor before promotion. A receiver implementing the specified current/previous acceptance would reject that credential even after both boxes have refreshed. Once forwarding requires an intermediate regional box, the failed-credential rule turns that rejection into 503.

Preserve and explicitly name current/.next acceptance, or specify the complete transition to a previous-key scheme, including signing and retention. Test successor publication, staggered refresh, promotion and removal; the proposed previous-key test alone does not cover today’s protocol.

Reviewed platform HEAD 7dcdf31e71c3852b6acdc4d74b20df9d77636f89 and flagship checkout 7c99ff8f1512f1a9ff3bf13337c3d147d730a6b6. No files changed; no builds, tests or infrastructure commands run.

---

FIRST PROMPT: Review spec 2 round 4 at the requested HEAD, read-only, against flagship Tofu.

WHAT: Confirm prior fixes and check forwarding, rollout and refresh-worker liveness.

STATUS: Review complete; two P2 findings remain.

NEEDED: Nothing.

RECOMMENDED: Specify the forwarding floor and reconcile the key-rotation contract before planning.

SESSION: Safe to close; nothing started or modified.

Verdict: not ready for an implementation plan.