Remove Proto asymmetric miner auth

[ankitgoswami]

Summary

• Removes Proto miner asymmetric auth/API-key pairing and switches the Proto plugin path to username/password credentials with default Proto credentials.
• Drops miner auth key storage from org/fleet-node schema, sqlc queries, fleet-node enrollment state, token/config wiring, and generated protobuf/sqlc/client outputs.
• Removes fake-rig auth-key endpoints and generated ProtoOS API surface, plus updates docs and UI copy from auth-key clearing to unpairing.

Verification

• bin/just gen
• cd plugin/proto && ../../bin/go test ./internal/device ./internal/driver ./pkg/proto ./tests/unit
• cd server && ../bin/go test ./internal/domain/plugins ./internal/domain/token ./cmd/fleetnode ./cmd/fleetd ./internal/fleetnode/bootstrap ./internal/domain/auth ./internal/domain/command ./internal/handlers/authz ./internal/handlers/fleetnode/gateway ./internal/handlers/fleetnode/admin ./internal/domain/fleetnode/enrollment ./internal/domain/fleetnode/pairing ./internal/domain/authz ./internal/domain/stores/sqlstores ./internal/domain/ipscanner -run '^$'
• cd client && npm test -- --run src/protoFleet/features/fleetManagement/components/MinerActionsMenu/useMinerActions.test.tsx
• cd server/fake-proto-rig && GOWORK=off ../../bin/go test ./...

Notes

• Full DB-backed fleetmanagement test still cannot run in this local environment because local Postgres rejects user=fleet authentication.
• Proto plugin integration test could not run here because Docker failed while building the test container (use of closed network connection).

[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 (1e923eb43ca2722b661a0ea0ecadecb41bed08c3...d31a2741eb60ebc25d266a70d92c1742d6c78b98, exact PR three-dot diff)
• Model: gpt-5.5

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

---

Review Summary

Overall Risk: HIGH

This PR removes asymmetric miner authentication across storage, token generation, plugin pairing, and SDK protobufs. The main risk is upgrade/rollback safety for existing Proto rigs that were paired under the old auth model.

Findings

[HIGH] Existing Proto Miners Can Lose Auth Material On Upgrade

• Category: Auth
• Location: server/internal/domain/plugins/plugin_factory.go:96
• Description: Runtime miner construction now only creates a UsernamePassword secret when encrypted device credentials exist. The previous asymmetric-auth bearer-token path was removed, while migration 000081 drops the org/fleet-node key columns. Existing Proto devices paired through asymmetric auth may not have miner_credentials rows, so after upgrade they resolve with an empty SecretBundle and the Proto driver rejects management operations.
• Impact: Existing paired Proto rigs can stop accepting telemetry, commands, password updates, and best-effort unpair flows after deployment. Rollback is also unsafe because the down migration recreates empty columns but cannot restore deleted key material.
• Recommendation: Stage this migration. Keep the old bearer fallback until every existing Proto device has encrypted username/password credentials, or add a backfill/remediation flow that proves credentials exist before dropping keys. Make rollback preserve key data until the final cleanup release.

[HIGH] Proto Unpair No Longer Revokes Legacy Device Auth Keys

• Category: Auth
• Location: plugin/proto/internal/device/device.go:960
• Description: Unpair used to call the rig’s auth-key deletion endpoint and now only clears local cache state. DeleteMiners still relies on miner.Unpair as the best-effort device-side cleanup path for Proto rigs, so legacy devices with an installed Fleet auth key are no longer told to remove it.
• Impact: Deleting/unpairing a legacy Proto rig can leave stale device-side trust in place. Any still-valid bearer tokens, retained private keys, backups, or older agents holding the key material may continue to authenticate until manual cleanup.
• Recommendation: Retain a legacy auth-key clear during Proto Unpair until a migration or device probe confirms the rig is credentials-only. Continue tolerating known default-password/unsupported responses, but attempt revocation for upgraded legacy devices.

[MEDIUM] SDK SecretBundle Removes APIKey Oneof Without Compatibility Window

• Category: Protobuf
• Location: server/sdk/v1/pb/driver.proto:285
• Description: The SDK protobuf reserves field 2 and removes the APIKey oneof arm. That avoids future field reuse, but it is still a breaking SDK/protocol change for out-of-tree or older plugin binaries that use the previous APIKey secret kind.
• Impact: Existing external plugins compiled against the prior SDK can fail pairing or device creation after host upgrade, and source users lose the API type without a versioned transition.
• Recommendation: Bump or negotiate the plugin SDK/API version, or keep APIKey as deprecated while rejecting asymmetric auth at a higher capability/policy layer. Document the compatibility break and migration path for third-party plugins.

Notes

No SQL injection, command injection, frontend XSS, pool hijack, or hardcoded wallet/pool redirection was evident in the reviewed diff. I reviewed .git/codex-review.diff only, per scope.

---

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