fix(security): admin auth on block-slot, block-producers, and wallet endpoints

[BossChaos]

Summary

Three unauthenticated endpoints exposed sensitive internal data:

Endpoint	Exposure	Severity
GET /block/slot	Internal slot scheduling, balance summary, producer turn timing	Medium
GET /block/producers	Miner wallet addresses, selection weights, device arch	Medium
GET /api/wallet/<wallet>	Any wallet balance, enrollment weight, tier, network age	Medium

Fix

Added _require_admin() guard (X-Admin-Key header vs RC_ADMIN_KEY env var) to:

• list_producers()
• get_current_slot()
• api_wallet_lookup()

Consistent with the auth pattern used throughout the RustChain codebase (bcos_routes.py, sophia_governor.py, etc.).

Files

• node/rustchain_block_producer.py: Added import hmac, _get_admin_key(), _require_admin(), auth on 2 endpoints
• node/rustchain_dashboard.py: Added import hmac, _get_admin_key(), _require_admin(), auth on 1 endpoint

[zqleslie]

Reviewed the security hardening PR adding admin auth to three information-disclosure endpoints.

Scope reviewed:

• node/rustchain_block_producer.py: _get_admin_key() + _require_admin() guard added to get_current_slot() and list_producers()
• node/rustchain_dashboard.py: Duplicate _require_admin() guard added to api_wallet_lookup()

Assessment:

1. Correctness: The _require_admin() pattern is identical to what's already deployed in rustchain_v2_integrated_v2.2.1_rip200.py for /withdraw/request, /governance/propose, and /governance/vote. This is consistent and low-risk.

2. Fail-safe: When RC_ADMIN_KEY is unset, returns 503 rather than allowing unauthenticated access. Good.

3. Endpoint impact:

   • GET /block/slot — exposes slot scheduling + balance summary → reasonable to protect
   • GET /block/producers — exposes miner addresses + weights → reasonable to protect
   • GET /api/wallet/<addr> — exposes any wallet balance → high value to protect, this is the most critical of the three

4. Minor note: _require_admin() is duplicated across rustchain_block_producer.py and rustchain_dashboard.py. Not a blocker for this PR, but worth consolidating into a shared module in a follow-up.

No blockers. If accepted, routing via bounty #73.

---

This is a review claim for maintainer assessment only.

[zqleslie]

Reviewed the security hardening PR adding admin auth to 3 endpoints across 2 files.

Endpoints secured:

• GET /block/slot → slot scheduling + balance summary (medium sensitivity)
• GET /block/producers → miner addresses, weights, device arch (medium sensitivity)
• GET /api/wallet/<addr> → any wallet balance, enrollment weight, tier (high sensitivity)

Assessment:

1. _require_admin() pattern is consistent — matches the existing auth guard in rustchain_v2_integrated_v2.2.1_rip200.py for /withdraw/request and governance endpoints. Uses hmac.compare_digest() for timing-safe comparison. Returns 503 when RC_ADMIN_KEY is unset, which fails closed correctly.

2. rustchain_block_producer.py: The _get_admin_key() and _require_admin() helpers are defined inside create_block_api_routes(), giving them access to Flask's request context via closure. This works correctly since Flask sets up request per-request in the same thread.

3. rustchain_dashboard.py: Same pattern, standalone functions using Flask's request global. api_wallet_lookup is the most critical endpoint here — exposing arbitrary wallet balances without auth is a real information-leak risk. The 503 fallback when RC_ADMIN_KEY isn't set is correct (better than 401, signals misconfiguration not bad credentials).

4. No blockers found — this is a clean, narrowly-scoped security fix. No runtime behavior changes beyond auth gating.

---

Review claim: bounty #73

[MolhamHamwi]

I reviewed node/rustchain_block_producer.py and node/rustchain_dashboard.py in this PR.

Two technical observations:

1. The fail-closed behavior is sound: _require_admin() returns 503 when RC_ADMIN_KEY is unset, so these newly protected endpoints do not accidentally remain public in a misconfigured deployment. Using hmac.compare_digest() for the provided X-Admin-Key also matches the existing constant-time comparison pattern used elsewhere in the project.

2. The route coverage looks consistent with the stated data-exposure scope: both /block/slot and /block/producers are guarded inside create_block_api_routes(), and /api/wallet/<wallet_address> is guarded before opening the SQLite connection, so unauthenticated callers are rejected before wallet/producer details are read. One small cleanup I noticed: hashlib is imported in rustchain_block_producer.py but does not appear to be used by this patch.

I received RTC compensation for this review.

[Scottcjn]

Holding for a maintainer call — the auth helper is well-built (constant-time, fail-closed 503-on-unset), but this gates read-only GET endpoints /block/slot, /block/producers, and /api/wallet/<addr> behind admin auth. Those are public telemetry the explorer/dashboard depend on, and /api/wallet/<addr> was just added (#6736) + is used by tooling — admin-gating it would break public balance lookups. If the intent is to hide producer weights specifically, let's scope it to that endpoint rather than the public balance/slot reads.

[Scottcjn]

Closing in favor of keeping these endpoints PUBLIC. /block/slot, /block/producers, and /api/wallet are intentional proof-of-antiquity consensus transparency that the explorer/dashboard depend on — admin-gating them breaks public balance/slot/producer lookups, and they expose no secrets (wallet balances + producer weights are public-by-design on a transparent chain). The one legitimate concern (device_info field exposure) is addressed by an explicit allowlist in the merged PR above, which keeps the endpoint public. Thanks for the careful auth helper — the same fail-closed pattern is great for the genuinely-sensitive write endpoints (#6719 etc.).