feat(hub): secret intake links — secure secret submission from chat

[zeroasterisk]

Why

When users interact with Scion agents via chat (Telegram, Discord), agents sometimes need secrets. Today users must leave the chat context to use CLI/web UI, or paste secrets in plaintext — a security anti-pattern that happened in the project's own history (raw GitHub PAT pasted into Telegram).

What

Secret intake links: a short-lived, JWT-secured URL that lets users paste a secret value directly into the Hub. The secret is stored as pending until the user confirms in the originating chat channel.

User flow

Agent → "I need your GitHub token: https://hub.example.com/intake#<JWT>"
User  → clicks link, pastes secret value
Hub   → stores as PENDING, sends to chat:
        "🔐 GITHUB_TOKEN submitted from Chrome/Mac at 203.0.113.42. Confirm?"
User  → confirms in chat
Hub   → secret becomes ACTIVE, available to agents

Security model

Protection	How
One-time use	Intake consumed after submission
Short-lived	15 min TTL default, 1 hour max
Rate limited	5 attempts per intake + per-IP token bucket
JWT signed	HS256 with Hub signing key, verified server-side
Pending gate	Value not usable until creator confirms in authenticated chat
Tamper evident	Submitter IP/UA shown in confirmation message
Zero-knowledge URL	JWT in fragment — never sent to server in HTTP request

How

New files (1,859 lines)

• pkg/hub/secret_intake.go — SecretIntakeService (in-memory, follows TelegramLinkService pattern), handlers for create/submit/confirm/reject, JWT generation/validation, rate limiting
• pkg/hub/secret_intake_test.go — 12 tests covering full lifecycle + security scenarios
• pkg/hubclient/secret_intake.go — SDK client for the intake API
• cmd/hub_secret_intake.go — scion hub secret intake KEY CLI command
• web/src/components/pages/secret-intake.ts — Lit component intake page (no login required)
• .design/secret-intake-link.md — Full design document with security analysis

Modified files

• pkg/hub/server.go — route registration + service lifecycle
• pkg/hub/auth.go — exempt intake submit endpoint from auth (JWT is the auth)
• pkg/hubclient/client.go — SecretIntake service accessor
• web/src/client/main.ts — register /intake page route

Test plan

• go build ./... passes
• 12 tests: create, submit, confirm, reject, expired, consumed, rate limiting, tampered JWT, unauthorized confirm, auth required, missing key, method not allowed
• All existing tests unaffected

[gemini-code-assist]

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.

[gemini-code-assist]

Concurrency Bug: Data Race on SecretIntake Fields

Returning a direct pointer to SecretIntake via GetIntake and then reading/writing its fields directly in the HTTP handlers (e.g., handleSubmitIntake, handleConfirmIntake, handleRejectIntake) without synchronization causes a data race with the background cleanupLoop goroutine, which concurrently reads and writes the same fields (like Status and PendingValue).

In Go, concurrent read/write access to struct fields without synchronization is undefined behavior and can lead to memory corruption or crashes.

Recommended Solution

Encapsulate the state transitions inside SecretIntakeService methods under the protection of s.mu. This ensures that all reads and writes to SecretIntake fields are fully synchronized. Alternatively, return a copy of the struct value instead of a pointer to prevent external modification without synchronization.

func (s *SecretIntakeService) GetIntake(id string) (SecretIntake, bool) {
	s.mu.Lock()
	defer s.mu.Unlock()
	intake, ok := s.intakes[id]
	if !ok {
		return SecretIntake{}, false
	}
	return *intake, true
}

[gemini-code-assist]

Bug: Missing Base64 Padding and UTF-8 Support in JWT Decoding

The client-side JWT decoding logic uses atob(payload) directly on the base64url-encoded payload segment. This has two major issues:

1. Missing Padding: JWT payloads are base64url-encoded without padding. If the payload length is not a multiple of 4, atob will throw a DOMException in most browsers, causing the page to fail to load and show the "Invalid Link" state.
2. UTF-8 Corruption: atob decodes strings as Latin-1. If the secret description or key contains non-ASCII UTF-8 characters, they will be corrupted (mojibake).

Recommended Solution

Add the necessary padding before calling atob, and decode the binary string as UTF-8.

Suggested change

	const payload = parts[1]
	.replace(/-/g, '+')
	.replace(/_/g, '/');
	const decoded = atob(payload);
	const payload = parts[1]
	.replace(/-/g, '+')
	.replace(/_/g, '/');
	const pad = payload.length % 4;
	const paddedPayload = pad ? payload + '='.repeat(4 - pad) : payload;
	const binaryString = atob(paddedPayload);
	const bytes = new Uint8Array(binaryString.length);
	for (let i = 0; i < binaryString.length; i++) {
	bytes[i] = binaryString.charCodeAt(i);
	}
	const decoded = new TextDecoder().decode(bytes);

[gemini-code-assist]

Security/Robustness: Missing Size Limit on Submitted Secret Value

There is no limit on the size of req.Value in handleSubmitIntake. Since the submitted secret is stored in memory (PendingValue) for up to an hour, an attacker could send extremely large values (e.g., tens of megabytes) to exhaust server memory and cause a Denial of Service (DoS).

Consider enforcing a reasonable maximum limit on the secret value size (e.g., 64 KB).

	if req.Token == "" || req.Value == "" {
		writeError(w, http.StatusBadRequest, ErrCodeValidationError, "token and value are required", nil)
		return
	}
	if len(req.Value) > 65536 {
		writeError(w, http.StatusBadRequest, ErrCodeValidationError, "secret value is too large (max 64KB)", nil)
		return
	}

[gemini-code-assist]

Validation Gap: Missing scope_id Validation for Project Scope

When creating an intake link, if req.Scope is set to "project", there is no validation to ensure that req.ScopeID is also provided and non-empty. If a client creates an intake with scope: "project" but leaves scope_id empty, the secret will eventually be persisted with an empty project ID, which could lead to orphaned secrets or security bypasses.

Consider adding a validation check to ensure ScopeID is present when the scope is "project".

	// Validate required fields.
	if req.Key == "" {
		writeError(w, http.StatusBadRequest, ErrCodeValidationError, "key is required", nil)
		return
	}
	if req.Scope == "project" && req.ScopeID == "" {
		writeError(w, http.StatusBadRequest, ErrCodeValidationError, "scope_id is required for project scope", nil)
		return
	}

[gemini-code-assist]

Robustness: Loose Path Matching in isUnauthenticatedEndpoint

The path matching logic for the unauthenticated submit endpoint uses a simple prefix and suffix check. This is quite loose and could accidentally match nested or malformed paths (e.g., /api/v1/secret-intake/some/nested/path/submit) that are not intended to bypass authentication.

Consider using a more precise check by splitting the path segments or using a regular expression.

	// Secret intake submit endpoint uses JWT in request body, not auth header
	if strings.HasPrefix(path, "/api/v1/secret-intake/") {
		parts := strings.Split(strings.TrimPrefix(path, "/api/v1/secret-intake/"), "/")
		if len(parts) == 2 && parts[1] == "submit" {
			return true
		}
	}

[gemini-code-assist]

Bug: Trimming Secret Values Can Corrupt Secrets

The submission logic trims the secret value before sending it to the server. Trimming leading or trailing whitespace can corrupt certain types of secrets where whitespace is significant (such as multi-line PEM private keys, SSH keys, or specific API tokens that may contain or end with whitespace).

Recommended Solution

Only use .trim() to check if the input is empty, but submit the raw, untrimmed value.

Suggested change

	if (!this.context || !this.secretValue.trim()) return;
	this.pageState = 'submitting';
	try {
	const res = await fetch(`/api/v1/secret-intake/${this.context.jti}/submit`, {
	method: 'POST',
	headers: { 'Content-Type': 'application/json' },
	body: JSON.stringify({
	token: this.token,
	value: this.secretValue.trim(),
	}),
	if (!this.context || !this.secretValue) return;
	this.pageState = 'submitting';
	try {
	const res = await fetch(`/api/v1/secret-intake/${this.context.jti}/submit`, {
	method: 'POST',
	headers: { 'Content-Type': 'application/json' },
	body: JSON.stringify({
	token: this.token,
	value: this.secretValue,
	}),

[ptone]

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

[zeroasterisk]

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]

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.