bmersereau tries to stop a backend secret from doing two jobs

A proposed hardening would have forced the user-API-key encryption secret to stand on its own - but it never landed.

securityinfrastructure

In Mike's backend, the routine that protects users' stored API keys was quietly willing to fall back on the same secret used to verify login tokens if no dedicated encryption secret was configured. bmersereau argued this broke a basic principle: one secret, one job. The proposed change ripped out that fallback and made the dedicated encryption secret mandatory - if it's missing, the system refuses to start rather than silently reusing the auth secret.

The pull request also brought along a small testing harness (vitest, a popular JavaScript test runner) to lock the new behaviour in, and claimed to close four open issues in the tracker. Build green, tests green - and then, after about two days, it was closed without merging. No reason given in the thread.

So what Worth a glance for anyone evaluating Mike's posture on key handling: the gap was flagged and a fix was offered, but the upstream maintainer chose not to take it.

View this fork on GitHub →

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