Scope Tinfoil prompt cache by user#234
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (2)
WalkthroughThe OpenAI proxy now applies provider-specific cache fields, including hashed Tinfoil user secrets. The Tinfoil proxy updates its Go toolchain and modules, while development and production PCR history files receive new signed records. ChangesProvider Cache Handling
Tinfoil Proxy Build Updates
PCR History Updates
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant get_chat_completion_response
participant apply_provider_managed_request_fields
participant ProviderAPI
Client->>get_chat_completion_response: Send completion request and user UUID
get_chat_completion_response->>apply_provider_managed_request_fields: Apply provider-specific fields
apply_provider_managed_request_fields-->>get_chat_completion_response: Return updated request
get_chat_completion_response->>ProviderAPI: Forward completion request
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/web/openai.rs (1)
1267-1270: 🔒 Security & Privacy | 🔵 TrivialUnsalted hash makes
user_cache_secretpredictable to anyone who knows the user's UUID.
tinfoil_user_cache_secretis a plainSHA-256(uuid_bytes)with no server-side key/salt. Since it's deterministic and derivable from just the UUID, any party that later learns a user's UUID (e.g. via logs, another API, or token claims) can recompute the exact same value sent to the third-party Tinfoil provider and correlate that user's cache entries across sessions — the field is functionally an obfuscated identifier rather than a secret. Consider deriving this with HMAC-SHA256 using a server-held secret key instead of a bare hash, so correlation requires server cooperation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/web/openai.rs` around lines 1267 - 1270, Update tinfoil_user_cache_secret to derive the cache secret with HMAC-SHA256 using a server-held secret key, rather than hashing user_uuid directly. Reuse the existing application secret/configuration mechanism and preserve deterministic output for the same user and key, while ensuring callers continue receiving the encoded digest string.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/web/openai.rs`:
- Around line 1267-1270: Update tinfoil_user_cache_secret to derive the cache
secret with HMAC-SHA256 using a server-held secret key, rather than hashing
user_uuid directly. Reuse the existing application secret/configuration
mechanism and preserve deterministic output for the same user and key, while
ensuring callers continue receiving the encoded digest string.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 6a994a73-f89a-47cc-a866-ff402d23c658
⛔ Files ignored due to path filters (1)
tinfoil-proxy/go.sumis excluded by!**/*.sum
📒 Files selected for processing (3)
src/web/openai.rstinfoil-proxy/Dockerfiletinfoil-proxy/go.mod
Summary
Testing
Summary by CodeRabbit
New Features
user_cache_secretfor the Tinfoil provider.Maintenance