Skip to content

fix(security): audit #16875's i18n authApiKey labels into the secrets baseline (#16942) - #16943

Closed
mrveiss wants to merge 1 commit into
mainfrom
issue-16942-secrets-baseline
Closed

mrveiss wants to merge 1 commit into
mainfrom
issue-16942-secrets-baseline

Conversation

@mrveiss

@mrveiss mrveiss commented Sep 18, 2026 •

Copy link
Copy Markdown
Owner

Closes #16942

Thinking Path

Secret Detection (whole tree) went red on #16916, which touches no locale file. The findings (en.json:9086, ur.json:9086, Secret Keyword) are the second authApiKey key that #16875 added to all 11 locales. The base is red, so every PR that merges main inherits it. That makes this one unblocking PR rather than a fix per PR.

Why only 2 of 11 locales: detect-secrets identifies a finding by (file, type, hashed_secret). In nine locales the new translation hashed to a value already audited in that file. en did not: the new value is "API key" (lowercase k), while the older key is "API Key". Neither did ur ("API کیلید").

They are UI labels, so the fix is the audited baseline. That is the documented mechanism, in docs/developer/RATCHET_BASELINES.md under "The secrets baseline: scan, audit, strip". No plugin, filter or allowlist change, and the UI string is not reworded to dodge the keyword regex.

What Changed

.secrets.baseline only, produced by the documented order on current main:

  1. Scan: detect-secrets scan --baseline .secrets.baseline (v1.5.0, the pinned rev).
  2. Audit: each new entry was inspected at its line and labelled is_secret: false.
  3. Strip: line_number removed from every entry.

The diff looks large (+221/−207), but almost all of it is the rescan reordering entries by current line number, which step 1 always does.

Acceptance criteria

  • The rescan lists every finding missing from the audited baseline, and each is inspected. It found exactly two:

    • en.json:9086: Secret Keyword
    • ur.json:9086: Secret Keyword

    They match the two CI findings on fix(kb): the RAPTOR tree is built at all, and its nodes cite their chunks (#14968) #16916. The scanner found those known positives, so its silence on the rest is a real result, not a scan that never looked.

  • Only confirmed non-secrets are labelled, and no line_number remains. Both hashes are recomputed from the visible labels:

    • sha1("API key") = cf678cab…
    • sha1("API کیلید") = 9235d7ec…

    After the strip, entries not labelled is_secret: false = 0, and entries carrying line_number = 0.

  • Secret Detection (whole tree) passes on this PR. Pending this PR's own CI run.

Verification

Old and new baselines compared as sets of (file, type, hashed_secret, is_secret, is_verified):

Entries
committed (main) 1358
this PR 1360
removed 0
added 2, the entries above

Outside results, the only field that changed is generated_at.

Model Used

Claude Opus 5 (claude-opus-5)

Summary by CodeRabbit

  • Chores
    • Updated secret-detection baseline records across multiple language files.
    • Refreshed the baseline generation timestamp.

… baseline (#16942)

#16875 added a second authApiKey key to all 11 locales without the scan,
audit, strip step from RATCHET_BASELINES.md. Nine translations hashed to
values already audited in their files; en ("API key") and ur did not, so
Secret Detection (whole tree) fails on every branch that merges main.

Followed the documented order on current main: full rescan (it found
exactly these two and nothing else), both inspected and labelled
is_secret false, line_number stripped. As sets the baseline gains two
entries and loses none; the rest of the diff is the rescan's reordering.
@mrveiss mrveiss added bug Something isn't working security ci labels Sep 18, 2026
@coderabbitai

coderabbitai Bot commented Sep 18, 2026 •

Copy link
Copy Markdown
Contributor

Review Change StackReview Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 7a7900d0-84ee-4a4a-8dd2-45aedb72290a

📥 Commits

Reviewing files that changed from the base of the PR and between bf3cac7 and 817c5aa.

📒 Files selected for processing (1)
  • .secrets.baseline

Included review availability: Your plan provides up to 10 included reviews per hour; 0 remain after this review.


📝 Walkthrough

Walkthrough

The secrets baseline updates hashed Secret Keyword findings for eleven locale files. It adds, removes, replaces, and reorders entries. The generation timestamp changes to 2026-09-18T05:32:44Z.

Changes

Secret baseline refresh

Layer / File(s) Summary
Locale findings and generation metadata
.secrets.baseline
The baseline updates audited findings for Arabic, German, English, Spanish, Persian, French, Hebrew, Latvian, Polish, Portuguese, and Urdu locale files. The generated_at value is updated.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 817c5

The refresh adds only the two intended audited locale findings and preserves the baseline format required by Secret Detection. The change is ready to merge.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Linked Issues check ❓ Inconclusive The changes address #16942. The baseline adds the two audited Secret Keyword findings for en.json:9086 and ur.json:9086, and sets both to is_secret: false. The summary states that the rescan f… Provide the completed Secret Detection (whole tree) result. A successful result is required to confirm full compliance with #16942.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly identifies the security baseline update for the i18n authApiKey labels from issue #16875. It accurately describes the main change.
Out of Scope Changes check ✅ Passed The pull request changes only .secrets.baseline. The added findings, line_number removal, and scan reordering directly support the rescan and audit procedure in #16942. The evidence reports no plu…
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Full details: Linked Issues check

Explanation

The changes address #16942. The baseline adds the two audited Secret Keyword findings for en.json:9086 and ur.json:9086, and sets both to is_secret: false. The summary states that the rescan found no other missing findings, removed all line_number fields, and preserved plugins, filters, allowlists, and UI strings. The remaining changes are scan reordering. However, Secret Detection (whole tree) is still pending, so the final acceptance criterion cannot be confirmed.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

Comment @coderabbitai help to get the list of available commands.

@mrveiss

mrveiss commented Sep 18, 2026

Copy link
Copy Markdown
Owner Author

Verified — merge first, ahead of everything that has merged main. main is red on Secret Detection (whole tree) at its head (bf3cac724, conclusion failure), so every branch refreshed from main inherits this red whatever it contains.

A secrets baseline is exactly where a real credential could be waved through, so the diff was checked as sets of findings keyed by (file, type, hashed_secret) rather than as text — the text diff is +221/−207 only because the rescan reorders entries:

Count
Entries on main 1,358
Entries on this branch 1,360
Added 2
Removed 0
Existing entries whose is_secret flipped 0

The two additions, both Secret Keyword and both is_secret: false:

  • autobot-frontend/src/i18n/locales/en.json — "authApiKey": "API key"
  • autobot-frontend/src/i18n/locales/ur.json — "authApiKey": "API کیلید"

Both are UI labels. detect-secrets' keyword plugin fires on the key name containing ApiKey, not on anything credential-shaped. Each file already carries an audited entry for an older authApiKey ("API Key", capital K); these second keys hash differently, which is why nine locales matched existing entries and these two did not.

Root cause, for the record: #16875 added a second authApiKey key to all 11 locales without the scan → audit → strip step in RATCHET_BASELINES.md. That PR was blocked in review for an unrelated reason (#16933) and merged anyway. Why its own run did not catch the new finding is not yet established — it may have merged before that run finished, which is itself worth knowing.

@mrveiss

mrveiss commented Sep 18, 2026

Copy link
Copy Markdown
Owner Author

Closing as a duplicate of #16961, which fixes the same main red with the identical two baseline entries (verified as sets: +2, 0 removed, 0 flipped on both). This one was correct and followed the documented full-rescan procedure — it is closed only because its whole-file reorder (+221/−207) would conflict with #16899 and #16895, which also modify .secrets.baseline, where #16961 adds 21 lines. No fault in the work.

@github-actions

Copy link
Copy Markdown
Contributor

Notice: 29 open PRs — past the runaway threshold (25)

There is no PR queue limit, and this is not a request to defer this PR. Work proceeds one issue at a time without a cap on open PRs; review capacity is the constraint.

This notice only means the count is high enough to be worth a glance for a runaway — something opening PRs in a loop, or a merge pipeline that has stalled so nothing is draining.

Currently open:

If the queue is draining normally, ignore this. Otherwise:

  1. Check whether CI is dispatching at all — see the ci-dispatch-watchdog status on these PRs
  2. Merge the ones whose CI has finished and review has passed: gh pr merge <number> --squash --delete-branch
  3. Look for a loop opening near-identical PRs

Warn-only runaway detector — .github/workflows/pr-queue-gate.yml. It never blocks a merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working ci security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant