feat: upgrade legacy managed Gateways to Tailscale auth - #1128
feat: upgrade legacy managed Gateways to Tailscale auth#1128TheAngryPit wants to merge 3 commits into
Conversation
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Codex review: needs real behavior proof before merge. Reviewed August 21, 2026, 5:09 PM ET / 21:09 UTC. ClawSweeper reviewWhat this changesThis PR adds a confirmation-gated upgrade for eligible managed Tailscale gateways that enables verified Tailscale dashboard identity while retaining shared-credential fallback. Merge readiness⛔ Blocked until stronger real behavior proof is added - 6 items remain Keep open. Current main still lacks the legacy managed-gateway upgrade path, but this feature changes an authorization boundary and the supplied Tailscale runtime proof is not from the reviewed head. Priority: P1 Review scores
Verification
How this fits togetherThe Windows Companion persists managed gateway records and produces dashboard URLs from tray and local MCP entry points. The change coordinates a Core configuration grant, a local trust marker, WSL Tailscale readiness checks, and credential fallback. flowchart LR
A[Managed gateway record] --> B[User confirms adoption]
B --> C[Core authorization setting]
C --> D[Persisted trust marker]
D --> E[Dashboard link service]
E --> F[Live WSL Tailscale check]
F -->|ready| G[Token-free dashboard]
F -->|not ready| H[Shared credential fallback or error]
Decision needed
Why: This is a deliberate expansion of the supported dashboard authorization boundary, not a correctness choice that tests can settle. Before merge
Findings
Agent review detailsSecurityNeeds attention: No supply-chain change was found, but the PR deliberately expands a dashboard authorization boundary and needs explicit maintainer approval. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Approve or decline the legacy-gateway authorization policy explicitly, then require one redacted current-head Tailscale adoption run that shows Core and local-state convergence plus token-free dashboard authentication. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR adds a new supported authorization path rather than reporting a current bug. The central current-head runtime flow has not been demonstrated in the supplied evidence. Is this the best way to solve the issue? Unclear pending maintainer policy approval. The service extraction follows the architecture ledger, but maintainers must decide whether the legacy identity authorization path should exist. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against d3ed6c78bf14. LabelsLabel justifications:
EvidenceSecurity concerns:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (16 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
|
Exact-head evidence for
Proof is @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
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. |
2 participants
What Problem This Solves
Fixes an issue where existing Companion-managed WSL Gateways remain token-backed for Dashboard access even after the operator explicitly adopts verified Tailscale identity authentication.
Closes #1117 only if maintainers approve the product and security boundary described there.
Why This Change Was Made
The Companion now offers a confirmation-gated migration for eligible active managed Gateways. It persists a durable trust marker, revalidates the authoritative Core policy, and requires live Tailscale readiness before generating a tokenless Dashboard URL. If readiness is unavailable, the existing approved browser credential remains available as fallback; without a fallback, the link fails closed.
This remains a thin Companion change. It adds no public Core API, alternate Gateway, automatic migration, credential deletion, installer change, or parallel recovery model.
User Impact
Operators can explicitly adopt Tailscale identity for an existing managed Gateway. Healthy Tailscale identity opens the Dashboard without a token in the URL. A transient readiness failure does not erase the durable opt-in or retained recovery credential.
Evidence
Exact current head:
c2b6c59530c0e648f80c10f509b151075392133eExact upstream main parent:
f8a8825ccbb441caaf51f5509102adb53aa1dbfcTrustTailscaleAuth=true; Core reportedgateway.auth.allowTailscale=true; the retained shared fallback credential remained present.end_to_end_provenevidence for the healthy tokenless branch.test_proven, notruntime_proven, on this host. The single productiontailscaledinstance owns both the local identity verifier and the reachable Tailscale Serve route. Stopping it would remove ingress as well as readiness and would not be an honest fallback test.Change Type
Scope
Validation
Fresh exact-head evidence:
c2b6c595.git diff --check: passed.Real Behavior Proof
c2b6c59530c0e648f80c10f509b151075392133e./usr/bin/tailscale status --json, and the Gateway recorded an authenticated Tailscale user for the private-window connection.Maintainer / Crabbox validation request
The remaining runtime gap should not block or destabilize a production host merely to manufacture a topology it does not have. If a maintainer or Crabbox user has a supported topology where Dashboard ingress remains reachable while the local WSL Tailscale verifier is unavailable, please validate this exact head:
A redacted transcript containing branch selection, verifier classification, credential-fragment presence as a boolean, marker/config preservation, and final authentication outcome is sufficient. Do not include the URL, token, device key, Gateway ID, or raw credential material.
Security Impact
/usr/bin/tailscale status --json.Compatibility and Migration
Review Conversations