willchen96 gives stored API keys their own lock

User API keys can no longer be encrypted with a borrowed credential - the project now demands a dedicated secret or refuses to run.

securityinfrastructure

When users store their own API keys, the backend encrypts them at rest. Until now, if the purpose-built encryption secret wasn't set, the system quietly reached for other credentials instead - including the master key that grants privileged access to the database. That coupling meant two unrelated things shared one secret, and rotating or redeploying either one could ripple into the other in ways nobody could easily predict.

The fix is small but pointed: user keys must be protected by a secret that exists for exactly that job. If it's missing, the backend now fails loudly and stops, rather than silently substituting a shared credential. That forces whoever runs the system to provision the right secret on purpose instead of leaning on a borrowed one by accident.

So what Anyone self-hosting or evaluating this fork's security posture should note the tightened separation between database access and how user secrets are stored.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from Open-Legal-Products/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
b4ba2742 fix: update encryption key retrieval to use only USER_API_KEYS_ENCRYPTION_SECRET; remove supabase secret key fallback willchen96 2026-05-16 ↗ GitHub

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-709.md from inside the repo you want the changes in.

⬇ Download capture-thread-709.md