Remove JWT-secret fallback from user API key encryption (closed without merge)

bmersereau proposed removing a fallback in the user-API-key encryption helper that would silently reuse the Supabase JWT verification secret when no dedicated encryption secret was configured. The PR closed after two days without merging.

securityinfrastructure

The concern was secret reuse: one key doing double duty for both auth token verification and at-rest encryption. The proposed fix removed the JWT-secret fallback and made the dedicated encryption secret a hard requirement, throwing when neither the primary nor its documented alias was set. Three unit tests verified the fallback was gone and the requirement was enforced.

The PR also introduced vitest as a dev dependency, wired up a test script, and added a config scoping the test runner to source rather than compiled output.

Build and tests passed, but the PR was closed without merge after roughly two days. No rationale was recorded, so it's not clear whether the approach was rejected, superseded, or simply abandoned. The same security concern and some of the same vitest scaffolding appear in subsequent open PRs from bmersereau, which suggests the work continued under different PRs rather than being dropped.

So what Skip this specific PR. The hardening it proposed has since been addressed in other open PRs from the same author that are still active. Check those instead.

View this fork on GitHub →

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