feat(hub): secret intake links — secure secret submission from chat#318
feat(hub): secret intake links — secure secret submission from chat#318zeroasterisk wants to merge 5 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements Secret Intake Links, enabling secure secret submission from chat channels via short-lived, one-time-use URLs. It adds a CLI command, backend handlers, an in-memory SecretIntakeService, and a standalone frontend page for anonymous submission. The review feedback identifies several critical issues: a concurrency data race on SecretIntake fields between handlers and the background cleanup loop; a client-side JWT decoding bug due to missing base64 padding and lack of UTF-8 support; a potential memory-exhaustion DoS vulnerability from a missing size limit on submitted values; a validation gap where scope_id is not verified for project-scoped secrets; loose path matching in the unauthenticated endpoint check; and a bug where trimming whitespace from submitted secrets can corrupt keys with significant whitespace.
|
could said link basically just bring you to the new secret dialog in the linked project the secret intake with no login, then confirmation in chat seems like a mild security risk surface |
|
Thanks for the feedback! We were going for a more versatile and zero-friction approach (works even if the user isn't near a browser session), but you're right that the no-login surface is unnecessary risk. Switching to a deep-link into the Hub UI with a simplified, focused secret-entry screen. The user must be logged in, the link pre-fills the key/scope/project/type from a JWT, and we'll send a notification to chat when the secret is stored. Dropping the anonymous intake page and the confirmation step. |
zeroasterisk
force-pushed
the
feat/secret-intake-link
branch
from
3e3da3f to
9cbfdc9
Compare
|
Round 3 review complete — 3 clean cycles, no new findings. Rebased on upstream/main (resolved 4 merge conflicts in server.go from upstream Discord link service additions). All tests pass. Design simplified per maintainer feedback: authenticated deep-link, no anonymous endpoints, no OTP/confirmation flow. 12 tests. |
zeroasterisk
force-pushed
the
feat/secret-intake-link
branch
from
8d1bf6c to
495021e
Compare
This is what we did |
…chat Agents in chat channels (Telegram, Discord) sometimes need users to provide secrets (API keys, tokens). Today users must either leave the chat to use the CLI/web UI, or paste secrets in plaintext in chat messages — a security anti-pattern. Secret intake links solve this: a short-lived JWT-secured URL that lets users paste a secret value directly into the Hub. The secret is stored in a pending state until the user confirms via the originating chat channel, where they can verify the submitter's IP and user-agent. Flow: 1. Agent calls POST /api/v1/secret-intake with key, scope, type 2. Hub returns a URL with JWT in fragment (never sent to server) 3. Agent sends URL in chat 4. User clicks, pastes value → stored as PENDING 5. Confirmation sent to chat with submitter IP/UA 6. User confirms → secret becomes ACTIVE Security: one-time use, 15 min TTL, rate limiting (5 attempts per intake + per-IP bucket), JWT signed with Hub signing key, pending value cleared on confirm/reject/expire. No login required on the intake page — the JWT is the authorization, confirmation is the gate. New files: - pkg/hub/secret_intake.go (716 lines) — handlers + service - pkg/hub/secret_intake_test.go (472 lines) — 12 tests - pkg/hubclient/secret_intake.go — SDK client - cmd/hub_secret_intake.go — CLI command - web/src/components/pages/secret-intake.ts — intake page - .design/secret-intake-link.md — design document Design doc: .design/secret-intake-link.md
Review findings and fixes: 1. TOCTOU race in submit handler: GetIntake + check status + update was not atomic. Concurrent submitters could both pass validation. Fix: new TrySubmit() method does all checks under a single lock. 2. GetIntake returned pointer to shared map entry. Callers could mutate the live record without holding the lock. Fix: GetIntake now returns a defensive copy. 3. Added 6 new tests: - TokenMismatch: JWT from one intake used on a different intake ID - DoubleConfirm: confirm an already-confirmed intake - SubmitMissingFields: missing token or value in submit body - RejectWrongStatus: reject intake that isn't pending confirmation - TTLCapping: TTL > 1 hour gets capped - ConfirmWrongStatus: confirm intake that isn't pending confirmation Total: 18 tests, all pass.
Redesign per maintainer feedback: replace the anonymous no-login intake page with an authenticated deep-link into the Hub web UI. Changes: - User MUST be logged in to submit a secret value (no anonymous endpoint) - Removed: pending/confirmation flow, OTP, PendingValue, SubmitterIP/UA, per-intake rate limiting, TrySubmit atomics - Simplified: intake record is just metadata + consumed flag - Secret is stored immediately on submit via secretBackend.Set() - Notification sent to originating chat channel on success - Auth exemption for submit endpoint removed from auth.go - Web intake page requires login, shows focused single-purpose form - Design doc updated to reflect simplified architecture Net: -450 lines. 12 tests covering the simplified flow.
…d validation, body limit Fixes from Gemini Code Assist review: 1. JWT base64url decode: add padding for atob + UTF-8 decode via escape/decodeURIComponent 2. scope_id validation: reject project-scoped intakes without scope_id 3. Body size limit: MaxBytesReader(128KiB) on store endpoint to prevent memory exhaustion 4. Don't trim secret values: whitespace may be significant in some secrets
zeroasterisk
force-pushed
the
feat/secret-intake-link
branch
from
495021e to
c84a492
Compare
2 participants
Problem
When users interact with Scion agents via chat (Telegram, Discord), agents sometimes need secrets. Today users must leave the chat to use the CLI/web UI, or paste secrets in plaintext — a security anti-pattern that has already happened in practice (a raw GitHub PAT was pasted into Telegram in this project's own history).
Solution
Secret intake links: a short-lived, JWT-secured URL that lets users paste a secret directly into the Hub, with a two-step confirmation flow to prevent injection attacks.
User flow
Security model
Alternatives considered
We chose intake links as the best tradeoff between security and UX for the chat context.
Reviewability roadmap
This is ~1,865 lines but the core logic is in one file:
pkg/hub/secret_intake.go— theSecretIntakeService: JWT generation, rate limiting, full lifecycle (create → submit → confirm/reject). Follows the existingTelegramLinkServicepattern.pkg/hub/secret_intake_test.go— 12 tests covering the full lifecycle + security edge casespkg/hubclient/secret_intake.go— SDK client (thin wrapper)cmd/hub_secret_intake.go— CLI commandscion hub secret intake KEYweb/src/components/pages/secret-intake.ts— Lit component for the intake pageserver.go(routes),auth.go(exempt submit endpoint — JWT is the auth)This PR could be split if you'd prefer to review the backend (Go) and frontend (Lit) separately — happy to do that on request.
Risk