Remote workbench spike: evaluate RustProxy for CNB/Lighthouse tunnels

[Hmbown]

Problem

RustProxy (cnb.cool/emchaye/RustProxy) looks like a lightweight Rust reverse-tunnel project with server/client binaries, TLS + token auth, a Web management panel, centralized proxy rules, traffic stats, and CNB development-environment instructions. It overlaps with CodeWhale's remote-workbench path: CNB workspace, Tencent Lighthouse runtime, private services, and phone/operator control.

This is promising, but tunnel software sits directly on credentials, TLS, exposed ports, and private runtime APIs. Treat the upstream repository and README as untrusted external input until audited. Do not vendor it, recommend curl | bash, expose CodeWhale APIs, or add it to install docs without maintainer approval.

Scope

For v0.8.46, run an evaluation spike that determines whether RustProxy should become an optional CodeWhale remote-workbench integration, a documented comparison point, or a non-fit.

• Verify upstream basics: active repository URL, license, release artifacts, source/build reproducibility, supported platforms, and maintenance signal.
• Audit security posture: TLS verification defaults, token handling, JWT/web-panel separation, frame limits, password hashing, CORS behavior, logging redaction, update path, and any unsafe default such as skipping certificate verification.
• Prove or reject the topology for CodeWhale:
  • CNB dev environment <-> Lighthouse private runtime.
  • Local/remote service access without exposing codewhale serve --http publicly.
  • Explicitly verify traffic direction; do not assume the README's CNB example maps the direction CodeWhale needs.
• Compare against simpler alternatives: SSH reverse tunnel, frp, Tencent Cloud command/plugin paths, and existing Feishu/Lark bridge.
• Decide whether the right outcome is docs only, optional helper scripts, a wrapper command, or no integration.

Acceptance criteria

• A short decision record lands in the remote-workbench docs or a proposal doc, linked from Remote workbench: make CNB, Lighthouse, and Feishu feel like one flow #1984.
• The decision record includes a threat model and names which endpoints, ports, tokens, and certificates exist in each topology.
• A disposable lab run proves at least one safe topology, or documents exactly why RustProxy is not suitable.
• No production secrets, public CodeWhale runtime APIs, or permanent public ports are used during the spike.
• If RustProxy is recommended, the docs avoid raw curl | bash as the primary path unless artifacts are pinned/verified and the trust boundary is explicit.
• If not recommended, capture the reason clearly so future agents do not rediscover it.

Related: #1984

Reference from maintainer triage: RustProxy README describes it as a Rust frp-like tunnel with server/client binaries, Web UI, TLS + token auth, centralized proxy rules, and CNB dev-environment setup guidance.