bmersereau wants every secret to stand on its own

A proposed rework would stop the backend from quietly reusing one master key across unrelated security functions.

securityinfrastructure

Right now, two separate jobs - signing the tokens that authorise downloads, and encrypting each user's stored API keys - can fall back to borrowing other values, including the platform's general secret key, whenever their own dedicated key is missing. bmersereau's fix removes those fallbacks and makes each key mandatory, so a leak of one value can't cascade into the other. To keep the guarantee honest, the change adds a startup check that refuses to boot if:

  • a required key is missing;
  • either key matches the shared platform secret; or
  • the two keys are set to the same value.

Silent misconfiguration becomes a loud crash on start. One catch flagged in the notes: an old, undocumented fallback is also being pulled, so operators who leaned on it must carry the value forward or risk making every stored user key unreadable. Worth knowing - the work was closed without merging, so none of it is live yet.

So what Anyone running a Mike fork in production should watch this pattern: it's the difference between one leaked secret and two entangled ones.

View this fork on GitHub →

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