fix(devlog): stop the audit record from breaking its own privacy gate - #2177
Conversation
The record documenting the shadow-marker leak pasted the reproduction transcript verbatim, including an sk-shaped value after a Bearer label. scripts/privacy-scan.ts matches those patterns wherever they appear, so dev's gates job went red again -- the same failure #2175 had just undone, reintroduced by the write-up describing it. The scanner cannot tell a fake credential from a real one, and it should not have to. Writing the two cases as shapes keeps the finding legible: the point was never the literal bytes, it was that controls are stripped before redaction and that the deny-list has no rule for one of the families. Both survive the rewrite.
|
✅ Deterministic PR hygiene checks passed. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughThe release audit replaces literal-looking bearer and Google API key examples with non-secret placeholders. It clarifies that the privacy scanner matches these patterns, including fake credentials, and removes a trailing blank line. ChangesRelease audit documentation
Estimated code review effort: 1 (Trivial) | ~3 minutes Merge Risk: ⚪ Minimal · up to This localized documentation change removes credential-shaped strings while preserving the audit record’s explanation, and no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
dev'sgatesjob is red again, and this time my own audit record caused it.The record documenting the shadow-marker leak pasted the reproduction transcript verbatim, including an
sk--shaped value after aBearerlabel.scripts/privacy-scan.tsmatches those patterns wherever they appear:This is the same failure #2175 had just undone, reintroduced by the write-up describing it. Worth stating plainly rather than quietly fixing: I hit the exact hazard I had documented one commit earlier.
The scanner cannot tell a fake credential from a real one, and it should not have to. Writing the two cases as shapes keeps the finding intact — the point was never the literal bytes, it was that control characters are stripped before redaction and that the deny-list has no rule for one of the two families. Both facts survive the rewrite, with a note at the code block explaining why it is written that way.
Verification
bun run privacy:scan— passed. Fails ondevwithout this change; verified both directions.Docs-only; no runtime code touched.
Checklist
This removes credential-shaped strings from the tree rather than adding any.
Summary by CodeRabbit