easterbrooka tightens the screws before the big encryption rewrite

Phase one of a security review: ship the hardening that doesn't need a key-management redesign, so the bigger change has a cleaner baseline.

securityinfrastructure

easterbrooka pushed a coordinated pass across logging, transport, secrets, and storage. Logs no longer leak PII, key prefixes, or auth headers, and the endpoint that reports which AI providers are configured now answers in plain yes/no rather than dribbling out fragments of the keys themselves. On the transport side, standard browser-security headers are now enforced, and the frontend can no longer silently fall back to a hardcoded backend address - every deployment has to declare where it's pointing.

The more interesting move is on secrets. Signed download links - the ones the chat hands users to retrieve their own files - used to be tied to the main Supabase database secret, meaning a routine key rotation would silently break every link already sitting in chat history. Those are now signed by a dedicated, separately-rotated secret. Uploaded files also get encrypted at rest on the way in.

So what If you're running a Mike fork in production, this is the boring-but-load-bearing tier of security work - worth a look before you build on top.

View this fork on GitHub →

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