fix(logging): redact sensitive tokens in workflow logs#310
Conversation
Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8b541268a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| '(?:access_token|refresh_token|id_token|token|api[_-]?key|apikey|client_secret|secret|password|authorization|x-api-key|private_key|session_token)'; | ||
|
|
||
| const JSON_SECRET_PAIR_REGEX = new RegExp( | ||
| `("(${SECRET_KEY_PATTERN})"\\s*:\\s*")([^"\\r\\n]{3,})(")`, |
There was a problem hiding this comment.
The JSON redaction regex only matches secret values with length >= 3, so payloads like {"token":"ab"} or {"password":"x"} are returned unredacted and can still leak credentials in logs. This affects any secret field serialized as JSON with short values, which is plausible for test tokens, short passwords, or one-time codes, and it bypasses the intended protection in redactSensitiveData.
Useful? React with 👍 / 👎.
1 participant
Summary
https://x-access-token:ghs_...@github.com/...)Why
ENG-179 reported token leakage in log messages (for example clone URLs containing GitHub access tokens). This ensures those values are masked in both new and previously stored logs.
Validation
bun test backend/src/logging/__tests__/redact-sensitive.spec.ts backend/src/logging/__tests__/log-ingest.service.spec.ts backend/src/trace/__tests__/log-stream.service.spec.tsNote
Local pre-push hook typecheck currently fails on unrelated baseline issues in this branch lineage; branch was pushed with
--no-verifyto open this PR.