Metbcy shuts a forged-download-link hole in Mike

A hardcoded fallback secret meant any misconfigured deployment could be tricked into serving files it shouldn't.

securityinfrastructure

Mike hands out documents through signed download links, protected by a cryptographic signature so a link can't be tampered with. The catch: when the signing secret wasn't configured, the code quietly fell back to a fixed placeholder value baked into the source. Because Mike's code is public, that placeholder was readable by anyone - so any deployment that shipped without the real secret set would happily accept forged links and hand back arbitrary stored files.

Metbcy removed the fallback entirely. Now a missing secret stops the system at startup with a clear error instead of running in a silently insecure state, and the setup docs finally list the secret as something operators must generate themselves. The fix was accepted back into the main project.

So what Anyone running their own Mike deployment should confirm they're on this version - the old default was an open door.

View this fork on GitHub →

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

Commits in this thread

1 commit from Metbcy/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date

eb441409 fix(security): fail fast when download HMAC secret is missing Metbcy 2026-05-03 ↗ GitHub

SHA	Subject	Author	Date
`eb441409`	fix(security): fail fast when download HMAC secret is missing	Metbcy	2026-05-03	↗ GitHub
commit body Resolves the issue where getSecret() silently fell back to the literal string "dev-secret" when neither DOWNLOAD_SIGNING_SECRET nor SUPABASE_SECRET_KEY was set. Because the codebase is public, that fallback let anyone forge valid /download/:token signatures against a mis-configured deployment. - Throw at first call instead of returning the hardcoded string, with a message pointing the operator at `openssl rand -hex 32`. - Document DOWNLOAD_SIGNING_SECRET in backend/.env.example so deployers following the README know to set it (and that it should be distinct from SUPABASE_SECRET_KEY). Closes #7

commit body

Resolves the issue where getSecret() silently fell back to the literal
string "dev-secret" when neither DOWNLOAD_SIGNING_SECRET nor
SUPABASE_SECRET_KEY was set. Because the codebase is public, that
fallback let anyone forge valid /download/:token signatures against a
mis-configured deployment.

- Throw at first call instead of returning the hardcoded string, with a
  message pointing the operator at `openssl rand -hex 32`.
- Document DOWNLOAD_SIGNING_SECRET in backend/.env.example so deployers
  following the README know to set it (and that it should be distinct
  from SUPABASE_SECRET_KEY).

Closes #7

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-714.md from inside the repo you want the changes in.

⬇ Download capture-thread-714.md