fix(proto): harden default-password server remediation

[ankitgoswami]

Summary

Hardens the server-side DEFAULT_PASSWORD remediation boundary introduced by #471. This PR keeps default-password miners telemetry-visible and remediation-resolvable, while preventing normal mutating commands, stale telemetry, stale pair reports, or cached handles from treating those miners as fully command-eligible.

Stack: #471 -> this PR. #482 is stacked on this PR and contains the hand-written Fleet UI remediation UX; #477 is also stacked on this PR and handles credentials-only fleet-node enrollment. The diff here is relative to #471 and intentionally excludes Fleet UI gating/cards, which moved to #482. Phase 3 key-auth deletion remains out of scope.

How it works

The command layer now resolves default-password miners only through explicit remediation paths. Password update and unpair can use paired-like resolution, while regular mutating commands still require paired-only resolution and fail fast for DEFAULT_PASSWORD. Fleet-node remote miners are admitted into the default-password state from pair reports, but password update is rejected before dispatch until the fleet-node protocol supports that command path.

Telemetry reconciliation repeats paired-like guards at the SQL update boundary and invalidates miner cache entries only when the persisted pairing state changes. That prevents late telemetry from resurrecting unpaired/auth-needed rows and prevents stale cached PAIRED miner handles from bypassing the new command guard. Plugin-side hardening reduces login churn and preserves default-password signal behavior through status polling.

Diagrams

flowchart TD
  T["Telemetry default_password_active"] --> R["guarded SQL reconcile"]
  R --> C{"state changed?"}
  C -->|"yes"| X["evict miner cache"]
  C -->|"no"| K["keep cached handle"]
  A["Command request"] --> B{"command type"}
  B -->|"password update / unpair"| P["paired-like resolver"]
  B -->|"normal mutating command"| O["paired-only resolver"]
  O --> G["DEFAULT_PASSWORD rejected"]
  P --> F{"remote fleet-node miner?"}
  F -->|"password update"| N["fail precondition before dispatch"]
  F -->|"unpair"| U["allow remediation"]

Loading

sequenceDiagram
  participant Poller as "Telemetry poller"
  participant DB as "device_pairing"
  participant Cache as "miner cache"
  participant Command as "command executor"

  Poller->>DB: reconcile DEFAULT_PASSWORD with current-row guard
  DB-->>Poller: rows affected + previous/current state
  alt state changed
    Poller->>Cache: evict miner handle
  end
  Command->>DB: resolve command target
  DB-->>Command: paired-only or paired-like result
  Command-->>Command: reject normal commands for DEFAULT_PASSWORD

Loading

Areas of the code involved

Area / package / file	What changed	Why it matters for review
server/internal/domain/command	Default-password command guard, paired-like remediation resolution, fleet-node password-update precondition, persistence tests	Main safety boundary for command eligibility
server/internal/domain/miner and server/sqlc/queries/miner_service.sql	Resolver modes for paired-only vs paired-like callers	Lets remediation resolve default-password miners without opening normal commands
server/internal/domain/telemetry and server/sqlc/queries/device.sql	Guarded default-password reconciliation and cache invalidation	Closes stale telemetry/cache races
server/internal/domain/stores/sqlstores and store interfaces	Query flags for default-password inclusion and metadata lookup	Keeps trusted metadata visible where needed while preserving command filters
server/internal/handlers/fleetnode/*, proto/fleetnodegateway/v1	Pair reports carry persisted default-password state back to nodes	Aligns fleet-node reporting with cloud persistence
plugin/proto and server/fake-proto-rig	Login refresh/default-password polling hardening and fake rig fixture updates	Keeps direct proto behavior stable under credentials auth
client/src/protoFleet/api/generated/fleetnodegateway/v1/fleetnodegateway_pb.ts, server/generated/**	Regenerated from proto/sqlc changes	Generated; review for staleness only

Key technical decisions & trade-offs

Decision	Trade-off
Separate paired-only and paired-like resolver modes	More explicit plumbing, but avoids accidentally command-enabling default-password miners
Reject fleet-node password update before dispatch	Leaves remote password remediation for a future protocol change, but avoids offering a guaranteed failing command path
Recheck paired-like eligibility inside SQL updates	Slight duplication of candidate predicates, but closes READ COMMITTED race windows
Evict miner cache only when reconcile changes persisted state	Avoids needless churn while removing stale handles after trust-state transitions
Move UI gating to #482	Keeps this review focused on backend safety, but the end-user affordances land in the next PR

Testing & validation

• cd client && npm run lint
• cd server && ../bin/go test ./internal/domain/telemetry -run 'TestReconcileDefaultPasswordState'
• cd server && ../bin/go test ./internal/domain/command -run 'TestExecuteCommand_UpdateMinerPassword_FleetNodeMinerFailsBeforeDispatch'
• cd server && ../bin/go test ./internal/domain/stores/sqlstores -run TestReconcileDefaultPasswordPairingStatusByIdentifier_DoesNotResurrectConcurrentNonPairedState -count=1 -v completed with no matching tests on this split branch.
• git diff --check

Not fully covered locally: full DB-backed package suites still require the local Postgres/testcontainers setup that has been flaky in this workspace.

[github-actions]

🔐 Codex Security Review

Note: This is an automated security-focused code review generated by Codex.
It should be used as a supplementary check alongside human review.
False positives are possible - use your judgment.

Scope summary

• Reviewed pull request diff only (c01deacc27c4d97727ebe3e469abffab22fca142...0ef25de2e85745b0f973a8b8db431c34b3ba3308, exact PR three-dot diff)
• Model: gpt-5.5

💡 Click "edited" above to see previous reviews for this PR.

---

Review Summary

Overall Risk: MEDIUM

Findings

[MEDIUM] Default-password miners drop out of fleet remediation views

• Category: Auth
• Location: server/sqlc/queries/device.sql:286
• Description: The new bucket logic treats DEFAULT_PASSWORD like a normal paired state: it is no longer included in the broken/needs-attention condition, and active miners with DEFAULT_PASSWORD can be counted as hashing. The same behavior is mirrored in the needs-attention filter and CSV export, where only AUTHENTICATION_NEEDED is surfaced as an auth remediation issue.
• Impact: Operators can miss miners still using factory credentials in aggregate health, filters, rollups, historical state snapshots, and CSV workflows. That weakens the new remediation signal and can leave devices exposed to unauthorized local-network access with known default credentials.
• Recommendation: Keep DEFAULT_PASSWORD telemetry/command eligibility separate from remediation visibility. Include it in needs-attention/broken counts and filters, or add an explicit “default password” remediation count/filter/export issue so operators can reliably find and rotate affected devices.

Notes

I did not find changed-hunk evidence of command injection, SQL injection, pool/wallet hijacking, breaking protobuf wire changes, frontend XSS, or new infrastructure secret exposure in this diff.

---

_{Generated by Codex Security Review |
Triggered by: @ankitgoswami |
Review workflow run}