What would you like?
spawn export scans staged files for known API-key shapes before creating the GitHub repo (packages/cli/src/commands/export.ts, the SECRET_REGEX in step 9). The current pattern covers OpenRouter (v1 only), Anthropic, OpenAI, GitHub, AWS, Hetzner, DigitalOcean, and PEM private keys. Worth widening before the feature sees wider use, since public-visibility exports depend on this as the last line of defence:
- OpenRouter: tighten from
sk-or-v1-[a-f0-9]{20,} to sk-or-[a-zA-Z0-9_-]{20,} so future-prefixed keys (sk-or-v2-…) and keys with non-hex chars still match.
- Slack:
xox[abp]-[0-9A-Za-z-]{10,} (bot/user/app tokens).
- Google service-account JSON: matches the full
\"type\":\\s*\"service_account\" block — BEGIN PRIVATE KEY already catches the key itself but not the surrounding creds JSON typical in ~/.config/gcloud/.
- Generic bearer headers in committed scripts:
Authorization:\\s*Bearer\\s+[A-Za-z0-9._-]{20,} — noisier but worth considering behind a --strict mode.
- Stripe live keys:
sk_live_[A-Za-z0-9]{24,}.
- Discord bot tokens:
[A-Za-z0-9_-]{24}\\.[A-Za-z0-9_-]{6}\\.[A-Za-z0-9_-]{27,}.
Context
Follow-up from the review of #3377. The default is now private (b96e643) and an interactive "make public?" prompt gates the visibility flip, so this is defence-in-depth rather than an acute leak. But public exports exist and the regex is the only runtime check, so coverage gaps here matter.
Suggested approach
- Extract
SECRET_REGEX to a named constant in export.ts (currently embedded in the bash script) with a comment per provider family.
- Add a unit test matrix that feeds sample keys for each provider through
grep -E against the regex to prevent regressions.
- Consider a
--strict flag that additionally runs gitleaks if available on the VM, with a clean fallback to the built-in regex.
Filed from Slack by SPA
What would you like?
spawn exportscans staged files for known API-key shapes before creating the GitHub repo (packages/cli/src/commands/export.ts, theSECRET_REGEXin step 9). The current pattern covers OpenRouter (v1 only), Anthropic, OpenAI, GitHub, AWS, Hetzner, DigitalOcean, and PEM private keys. Worth widening before the feature sees wider use, since public-visibility exports depend on this as the last line of defence:sk-or-v1-[a-f0-9]{20,}tosk-or-[a-zA-Z0-9_-]{20,}so future-prefixed keys (sk-or-v2-…) and keys with non-hex chars still match.xox[abp]-[0-9A-Za-z-]{10,}(bot/user/app tokens).\"type\":\\s*\"service_account\"block —BEGIN PRIVATE KEYalready catches the key itself but not the surrounding creds JSON typical in~/.config/gcloud/.Authorization:\\s*Bearer\\s+[A-Za-z0-9._-]{20,}— noisier but worth considering behind a--strictmode.sk_live_[A-Za-z0-9]{24,}.[A-Za-z0-9_-]{24}\\.[A-Za-z0-9_-]{6}\\.[A-Za-z0-9_-]{27,}.Context
Follow-up from the review of #3377. The default is now private (b96e643) and an interactive "make public?" prompt gates the visibility flip, so this is defence-in-depth rather than an acute leak. But public exports exist and the regex is the only runtime check, so coverage gaps here matter.
Suggested approach
SECRET_REGEXto a named constant inexport.ts(currently embedded in the bash script) with a comment per provider family.grep -Eagainst the regex to prevent regressions.--strictflag that additionally runsgitleaksif available on the VM, with a clean fallback to the built-in regex.Filed from Slack by SPA