bmersereau makes the backend fail loud on secret reuse
A quiet config footgun in the Mike backend becomes a startup-time refusal.
Two different cryptographic jobs in Mike's backend - signing download links and encrypting users' stored API keys - had been quietly falling back to the same Supabase service key (or a shared legacy variable) when their own settings weren't configured. That's the kind of misconfiguration nobody notices until an incident report explains it. bmersereau rips out the fallbacks and forces each purpose to use its own dedicated, distinct secret.
The enforcement runs at boot: if either secret is missing, reuses the Supabase key, or matches the other, the server refuses to start. Eleven unit tests cover the success and failure paths, and the PR is open against the upstream project, closing four related issues in one shot. Operators upgrading need to read the migration note carefully - one of the secrets must be carried forward verbatim, or every stored user API key becomes unreadable.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?