Redact secrets from CLI logs, not just CI logs

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code

[ninadbstack]

What

sendBuildLogs applied redactSecrets to cilogs but sent clilogs through untouched:

constlogsObject={clilogs: logger.query(log=>!['ci'].includes(log.debug))// ← unredacted};
...
logsObject.cilogs=redactSecrets(logger.query(...));// ← redacted

CLI log entries are the ones that can carry foreign response text — SDK error messages interpolate fields from remote HTTP responses — and /logs content is retrievable via GET /api/v1/logs by anyone who passes authorize(build, :read?), i.e. any project member. There is no server-side redaction on that path. So the half most likely to hold upstream data was the half we weren't redacting.

This routes clilogs through the same existing redactSecrets helper. No new patterns, no new mechanism — secretPatterns.yml already ships ~1750 rules including AWS Access Key ID / cred-file shapes.

Why the memoization is in the same PR

redactSecrets recurses per log entry, and each call did readFileSync + YAML.parse of the ~1750-rule pattern file and recompiled every regex. That was already wasteful for cilogs; sending clilogs (the larger set) through it would have made it a real cost on big builds. Patterns are now parsed and compiled once.

Reusing the /g regexes across replace() calls is safe — String.prototype.replace resets lastIndex on a global pattern, verified:

0 "x [REDACTED] y" lastIndex= 0
1 "x [REDACTED] y" lastIndex= 0
2 "x [REDACTED] y" lastIndex= 0

Behavior notes

• No change for legitimate users or for support: the full message is preserved, only credential-shaped substrings become [REDACTED].
• The in-place mutation of logger entries is unchanged from the existing cilogs path and matches the contract documented at packages/logger/src/logger.js:137-146.

Testing

Added redacts secrets from CLI logs, not just CI logs to packages/core/test/percy.test.js — decodes the actual posted /logs payload and asserts the key shape is absent from clilogs and [REDACTED] is present.

Draft because I could not run the suite — node_modules isn't installed in my environment and installing deps is out of scope there. Files pass node --check; the regex-reuse claim above is verified standalone. Please let CI run before marking ready.

Context

Found while assessing PER-9354. That chain finding itself does not reproduce (details in the ticket) — this is an independent gap surfaced along the way, and it stands on its own merits.

🤖 Generated with Claude Code