feat: upgrade legacy managed Gateways to Tailscale auth - #1128
feat: upgrade legacy managed Gateways to Tailscale auth#1128TheAngryPit wants to merge 7 commits into
Conversation
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs maintainer review before merge. Reviewed August 22, 2026, 6:22 AM ET / 10:22 UTC. ClawSweeper reviewWhat this changesThe PR adds a confirmed in-place upgrade for existing managed Tailscale gateways that enables Core-verified identity dashboard access while preserving shared-token fallback. Merge readinessKeep open for a maintainer security-boundary decision. Current main supports the same explicit Tailscale trust model for new setup, but does not provide this in-place migration for existing managed gateways; the patch’s Core readback and live-ingress checks make it a viable candidate rather than an obsolete duplicate. Priority: P2 Review scores
Verification
How this fits togetherThe Windows Companion persists managed gateway records, connects them to Core, and generates dashboard links for WinUI and local MCP callers. This change takes an explicit Connection-page opt-in through Core configuration and a durable local marker, then revalidates Core and Tailscale ingress before omitting a browser credential. flowchart LR
A[Existing managed gateway] --> B[Connection settings confirmation]
B --> C[Core configuration patch]
C --> D[Durable gateway trust marker]
D --> E[Core readback]
E --> F[Live Tailscale ingress verification]
F --> G[Dashboard link policy]
G --> H[Browser or local MCP link]
Decision needed
Why: The implementation is bounded and proof-positive, but accepting tailnet identity for installed legacy gateways is an authorization-policy extension that cannot be settled by tests alone. Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Either approve this narrowly scoped legacy migration under the existing explicit Tailscale trust policy, or retain the current fresh-setup-only boundary and close the PR as an intentionally unsupported upgrade path. Do we have a high-confidence way to reproduce the issue? Yes, source-reproducible: current main supports TrustTailscaleAuth during fresh setup but has no durable legacy-record marker or in-place upgrade action for an existing managed gateway. Is this the best way to solve the issue? Yes, conditionally: the PR reuses the existing explicit Core authorization setting and preserves fallback behavior, but the legacy authorization-policy extension needs maintainer approval. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ccd64bbb7d68. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (17 earlier review cycles; latest 8 shown)
|
|
Thanks for flagging the Both pass the submitted object to The regression test deliberately verifies that an unrelated top-level field is absent from the submitted patch. I added a source comment documenting this invariant; no behavior changed in that follow-up commit. The draft remains blocked on the product/security decision in #1117 and does not claim exact-head runtime proof for the new failure branches. @clawsweeper please re-review the updated head. |
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
CI follow-up on exact head The setup-connect E2E exposed a real regression in The fix removes only that guard. Existing behavior remains:
Fresh proof after the correction:
The draft remains blocked on #1117's product/security decision and exact-head runtime-proof gate. The new CI run is the supported E2E proof for this head. |
|
Exact-head architecture and upstream reconciliation proof for
Fresh proof after the merge:
The first closeout run had one unrelated telemetry-listener test failure. The exact test passed on one bounded rerun, and the canonical closeout then passed in full; no telemetry code was changed. This is test/build/review proof, not current-head runtime or end-to-end proof. The draft remains blocked on the legacy-gateway authorization-policy decision and an inspectable redacted runtime artifact showing Core/local convergence, retained fallback credentials, and token-free Dashboard authentication. |
b57cc9c to
afc9111
Compare
Current-head Windows runtime proofI tested the published #1128 head as part of a combined Windows Companion candidate at The supported build passed all five projects. Focused validation passed 1,073 tests with zero failures, and the canonical Shared/Tray closeout passed 5,896 tests with zero failures (32 existing integration-category skips). The exact candidate was then installed and exercised through the supported {
"revalidated": true,
"success": true,
"trustTailscaleAuth": true,
"credentialFragmentPresent": false,
"errorCode": null
}This provides runtime proof that the installed Companion revalidated the authoritative Core setting and produced a successful trusted-auth dashboard result without including the retained fallback credential. No browser or Launcher was invoked, and no URL, token, endpoint, gateway identifier, or raw Core response was persisted. The temporary Local MCP proof surface was returned to Scope note: this Gateway had already adopted trusted auth, so the proof exercises current-head revalidation and token-free result construction rather than replaying the initial Sanitized agent transcript@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Addressed the remaining contributor-owned localization finding on exact head 653135c.
Validation:
The maintainer policy decision for the legacy identity authorization boundary and current-head proof of the initial untrusted-to-trusted transition remain open gates; this commit does not claim to resolve either. |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
Initial-adoption proof — provenance correctionCorrection: the installed combined Windows build The operator and Codex ran one bounded, explicitly authorized, reversible transition through the installed Companion's supported Connection UI. The transition observations and receipt below are runtime evidence for the authentication implementation at The current PR head is one descendant commit ahead. Its complete Accordingly, the strongest accurate proof is: Sanitized result: {
"status": "pass",
"proofLevel": "runtime_proven_plus_exact_head_equivalence",
"runtimeProvenPrCommit": "afc91117402e0ca46834faee791150ded570a90a",
"currentHead": "653135ce02ad3814604879b516b8e18e7f1b4593",
"currentHeadDelta": "localization_only",
"initial": {
"coreAllowTailscale": true,
"localTrustMarker": true,
"sharedFallbackPresent": true
},
"controlledReset": {
"coreAllowTailscale": false,
"localTrustMarker": false,
"sharedFallbackRetained": true
},
"adoption": {
"entrypoint": "supported_companion_connection_ui",
"fallbackReconnectSucceeded": true,
"coreAllowTailscale": true,
"localTrustMarker": true,
"sharedFallbackRetained": true
},
"rollback": {
"originalBooleanStateRestored": true,
"companionRunning": true
}
}What this proves:
The receipt SHA-256 is Receipt provenance note: the hashed receipt's Redaction: no URL, token, Gateway identifier, raw response, or secret value was persisted or included here. No update was installed. The two disposable identity runtimes used during diagnosis were removed after verification. This closes the behavioral initial-adoption proof gap through runtime evidence for |
|
@clawsweeper re-review |
clawsweeper
Bot
added
proof: sufficient
|
@clawsweeper re-review |
653135c to
b51aa91
Compare
clawsweeper
Bot
removed
rating: 🐚 platinum hermit
b51aa91 to
c2b6c59
Compare
Current-head runtime proof and bounded remaining askThe PR branch is now rebuilt as one exact commit, Current-head production-path evidence:
The remaining negative-readiness branch is deliberately reported as Maintainer or Crabbox-user request: if you have a supported topology where Dashboard ingress remains reachable while the local WSL Tailscale verifier is unavailable, could you run the four-step fallback/recovery check now documented in the PR body? A redacted transcript with boolean credential-fragment presence, marker/config preservation, and authentication outcome is enough. Please do not include URLs, tokens, Gateway identifiers, or credential values. This limitation is a topology-specific proof gap, not a request to weaken the safety checks or to block the larger current-main validation picture. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
c2b6c59 to
e34272f
Compare
e34272f to
bd8ab21
Compare
clawsweeper
Bot
added
P1
|
Exact-head follow-up for What changed
Validation
Real behavior proof
Proof hashes: WinUI executable The remaining question is the maintainers' intended policy for enabling verified Tailscale dashboard identity; this follow-up deliberately leaves that decision explicit. @clawsweeper please re-review the exact head. |
|
CI follow-up for exact head
This is evidence of an unrelated timing-sensitive UI test gate, not a failure of the dashboard-link behavior changed by this PR. Maintainer action requested: rerun failed jobs. The PR remains honestly CI-red until that rerun passes; no timeout/harness change has been mixed into this dashboard/auth patch. |
|
Exact-head current-main reconciliation and real Core compatibility proof for
Compatibility boundary: the retained shared-credential fallback remains intentional while live ownership revalidation is unavailable. This does not claim every link is always token-free or that restart recovery is atomic. The contributor-owned proof gap is now closed at @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
P2
2 participants
What problem this solves
Existing Companion-managed WSL Gateways can remain token-backed for Dashboard access after the operator explicitly adopts verified Tailscale identity authentication.
Closes #1117 only if maintainers approve the product/security boundary below.
Core-first design
Official Core owns the authorization and ingress contract. The Windows Companion adapts to Core; this PR does not patch, replace, or require a compatibility change in Core.
The Companion now offers a confirmation-gated migration for eligible active managed Gateways. It:
gateway.auth.allowTailscale;Exact source
0ad95b5edc4ce3745a4724d171a73447df7a1a03ccd64bbb7d687d9929091109c8d722ad9ba962d9f68503084b7ad967d9ba763dbe06065d8762042f(2026.8.1)032B956F7B42FD356AF37C15EF571FF2A1BFE97BDB50AAAE22614FDBF3790C0BValidation
ConnectWithSharedTokenAsync_RevalidatesDurableTokensUnderTransitionSemaphoretimeout already reproduced on the clean parent baseline.git diff --check: PASS.The first full-Connection attempt also hit seven current-main Local AI fixture failures because the system drive lacked space for their synthetic model files. Re-running the unchanged suite with
TEMPon the project drive removed all seven environmental failures.Exact-head real behavior proof
The exact Release binary ran side-by-side against unmodified official Core and its Core-owned managed Tailscale ingress.
{ "ownershipClassification": "owned", "dashboard": { "scheme": "https", "queryEmpty": true, "fragmentEmpty": true, "hasTokenQuery": false, "hasCredentialMarker": false, "httpStatus": 200, "expectedControlUiContent": true }, "browser": { "openedTokenFree": true, "boundedControlUiMarkers": 2, "boundedConnectMarkers": 1, "boundedAuthFailures": 0 } }No URL, hostname, token, Gateway/device/pairing identifier, Tailscale identity, private path, or raw journal line is included.
The exact candidate, local MCP listener, temporary config and disposable Gateway runtime were removed after proof. Local MCP was restored to disabled. The installed production Companion and all credentials/pairings were untouched.
Compatibility truth
The existing fallback remains intentional. During a disposable Core restart, the first immediate request used the approved shared-credential fragment while ownership revalidation converged; a later request returned to a token-free URL and HTTP 200. Therefore this PR does not claim that every link is always token-free or that restart recovery is atomic.
Maintainer decision
Should an explicitly opted-in existing managed Gateway be allowed to authorize Control UI access through Core-verified Tailscale identity, with authoritative Core readback, Core-process ownership verification, retained shared-credential fallback, and fail-closed behavior when no approved path exists?
Contributor recommendation: approve this bounded Core-owned authorization path.
Proof level
implemented,code_proven,test_proven, andruntime_provenfor exact-head token-free Control UI link generation/opening against unmodified official Core. Merge, release, installed-package promotion, and the maintainer policy decision remain unclaimed.