Secret Detection red on main: #16875's i18n authApiKey labels not in the audited baseline

Problem

Secret Detection (whole tree) fails on every PR that has merged current main. First seen on #16916, which touches no locale file:

potential secret not in the audited baseline: autobot-frontend/src/i18n/locales/en.json:9086: Secret Keyword
potential secret not in the audited baseline: autobot-frontend/src/i18n/locales/ur.json:9086: Secret Keyword

Root cause

#16875 (bb1e3518d, MCP server admin CRUD) added a second authApiKey key to all 11 locales. detect-secrets' Secret Keyword plugin matches any *ApiKey-shaped key with a quoted value. Its identity for a finding is (file, type, hashed_secret), so:

9 locales pass: their translated value was already audited in the same file.
en and ur fail: "API key" (lowercase k; the older key is "API Key") and "API کیلید" are new hashes in their files.

These are UI labels, not credentials. #16875 merged without the scan → audit → strip step from docs/developer/RATCHET_BASELINES.md ("The secrets baseline: scan, audit, strip").

Fix

Follow that documented procedure on current main: rescan, label only the new entries is_secret: false after inspecting each, strip line_number. No allowlist widening, no plugin or filter change, no reword of the UI string to dodge the regex.

Acceptance criteria

The rescan of current main lists every finding missing from the audited baseline, and each is inspected
Only entries confirmed as non-secrets are labelled is_secret: false; the baseline carries no line_number
Secret Detection (whole tree) passes on the fix PR

How it reached main without a red is #16863: the whole-tree scan's pull_request trigger is path-filtered, and #16875 was frontend-only, so the scan never ran on it. #16943 fixes the symptom; #16863 is the cause.

Duplicate of #16960 — the same main-red cause (the authApiKey label in en/ur never baselined), found independently by two sessions. Fixed by PR #16961.

Branch issue-16942-secrets-baseline is redundant and is being deleted. Main's audited baseline already covers the gap this issue named.

Check (the one set as #16942's follow-up, run after #17108 merged), on main at b87343a50f:

detect-secrets-hook --baseline .secrets.baseline <the 11 i18n locale files containing authApiKey>: exit 0, no finding.
Control, to rule out a check that didn't look: the same 11 files against a copy of that baseline with results emptied report 632 locations. The scan does detect these labels, and main's baseline accounts for all of them. It has 11 src/i18n result entries.

What the branch held: a .secrets.baseline-only diff (+221/−207) plus main merges. Its PR #16943 is closed, and no worktree uses it.

Restore point: head e1ade7c1d3291cbfa55912829538de5394ffa411. git push origin e1ade7c1d3291cbfa55912829538de5394ffa411:refs/heads/issue-16942-secrets-baseline brings it back.

Navigation Menu

Repository navigation

Secret Detection red on main: #16875's i18n authApiKey labels not in the audited baseline #16942

Problem

Root cause

Fix

Acceptance criteria

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Secret Detection red on main: #16875's i18n authApiKey labels not in the audited baseline #16942

Description

Problem

Root cause

Fix

Acceptance criteria

Activity

mrveiss commented on Sep 18, 2026

mrveiss commented on Sep 18, 2026

mrveiss commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions