refactor(api): remove RSA signature gate from initial setup flow

[geovannewashington]

What changed

Removed the RSA-based signature requirement from the setup flow and simplified the initial setup process.
The /setup endpoint no longer requires a sign query parameter and no longer performs cryptographic validation.
The setup script was updated to remove signature generation and now directly opens (or prints) the setup URL.

Cleanup was performed across:

• setup HTTP handler
• setup service interface and implementation
• CLI setup script

Why

The previous setup flow introduced unnecessary complexity for a one-time initialization process.

Most self-hosted systems use a first-user-wins model where initialization is controlled by a persistent system state instead of cryptographic verification.

How to test

1. Reset the environment
   docker compose down -v
2. Start the stack
   make start
3. Verify initial state
   curl http://localhost/info | jq
   Expected: setup: false
4. Create the first admin user via CLI
5. Verify setup is completed
   curl http://localhost/info | jq
   Expected: setup: true

Fixes: #6154

[github-actions]

Claude finished @geovannewashington's task in 4m 13s —— View job

---

Code Review Complete

Reviewed 3 files. 2 inline issues posted (1 critical, 1 medium).

Summary

The core handler and service changes are clean — the signature gate removal and interface simplification look correct. No cross-repo impact was found in cloud/.

However, the PR is incomplete: the test file (api/routes/setup_test.go) and auto-generated mock (api/services/mocks/services.go) still reference the removed SetupVerify method, and the orphaned PrivateKeyPath constant should be cleaned up. See inline comments for details.

Additional notes

Security consideration: The previous RSA signature served as proof-of-server-access — only someone who could run the CLI (and read the private key) could complete setup. The new "first-user-wins" model removes this requirement, meaning any network-reachable client can call /api/setup during the window between server start and first admin creation. For instances exposed on public IPs, this window could allow an unauthorized party to create the first admin account. This is an intentional design choice per the PR description, but worth acknowledging as a tradeoff. A lightweight alternative (e.g., a random setup token printed to server logs at startup) could preserve simplicity while still proving server access.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[github-actions]

critical: The tests in api/routes/setup_test.go were not updated to match this simplified handler. The test file still:

1. Sends ?sign=value query parameters (lines 42, 49, 61, 75, 96) which are now silently ignored
2. Sets up servicesMock.On("SetupVerify", ...) mock expectations (lines 69, 83, 104) for a method the handler no longer calls — these expectations go unfulfilled
3. Contains test cases for removed behavior: "fail to get the signature" and "fail to validate the signature"

The tests may still compile and even pass accidentally (e.g., empty body still returns 400 from Bind), but they give false confidence — they're testing phantom code paths rather than the actual simplified flow.

The test file needs to be rewritten to:

• Remove the queries field and all ?sign=value references
• Remove all SetupVerify mock expectations
• Remove the "fail to get the signature" and "fail to validate the signature" test cases entirely
• Add servicesMock.AssertExpectations(t) alongside the existing envMock.AssertExpectations(t) to catch stale mock registrations going forward

Fix this →

[github-actions]

medium: Two cleanup items left behind:

1. PrivateKeyPath (line 13) is now unused — its only consumer was the removed SetupVerify method. It should be removed to avoid implying this path is still operationally relevant.

2. The auto-generated mock at api/services/mocks/services.go still contains a SetupVerify method (lines 1454–1470) that is no longer part of this interface. The mock should be regenerated (e.g., go generate ./api/services/...) to stay in sync.

Fix this →

[otavio]

/review

[github-actions]

Claude finished @otavio's task in 6s —— View job

---

Code Review Complete

Reviewed 6 files. 1 inline issue posted (1 critical).

Summary

The backend changes (Go handler, service, mocks) are clean — the signature gate was removed correctly, the SetupVerify method and PrivateKeyPath constant are fully gone, and there's no cross-repo impact in cloud/. No security vulnerabilities were introduced.

However, the PR is incomplete: the frontend and OpenAPI spec still enforce the removed sign parameter, which will break the setup UI for users. See the inline comment on api/routes/setup.go for the full list of files that need updating.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 5m 17s —— View job

---

Code Review Complete

Reviewed 13 files across code quality, security, testing, Go/TypeScript patterns, and architecture — no issues found.

Summary

The signature gate removal is clean and complete across backend, frontend (both Vue and React UIs), and OpenAPI spec:

• Backend (Go): Handler simplified correctly — SetupVerify and PrivateKeyPath fully removed, SetupService interface properly reduced, mocks regenerated cleanly.
• Security: The "first-user-wins" guard (system.Setup check in setup.go:19) correctly prevents repeated exploitation of the endpoint. Input validation and password hashing remain intact.
• Tests: Updated test cases properly match the simplified flow. Removed test cases were for phantom code paths (sign validation). Remaining tests cover bind failure, validation failure, service failure, and success.
• Frontend: Both Vue and React UIs correctly remove the sign step, sign state, and related UI elements. Step numbering updated consistently.
• Cross-repo: No impact on cloud/ — SetupVerify, SetupService, and PrivateKeyPath have zero references there. The BillingEvaluate/BillingReport removals in the mock are correct (stale methods from a previous interface version, cleaned up by mockery regeneration).
• Old Vue UI client: The generated client (ui/src/api/client/api.ts) was intentionally not regenerated as the old UI is discontinued — the empty-string workaround in users.ts:56 and matching test URL in users.spec.ts:133 are functional and consistent with this decision.

---

If you push additional changes and want a new review, tag @shellhub-io/admin and a team member can trigger it.