Fix Security workflow failing on 40-character test names - #2489
Merged
Conversation
Through v3.96.0 the Lob detector matches `test_` plus 35 word characters, so every 40-character pytest function name is flagged as a Lob key. Lob's API answers 403 for those, which that version reads as "verified", failing the Security workflow on any PR that adds such a test. Fixed upstream in 43b8e371a but unreleased, and the action pulls the released :latest image. We don't use Lob, so exclude the detector in CI and in the pre-commit hook.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
The
secretsjob in the Security workflow fails on any PR that adds a pytest function whose name is exactly 40 characters long. TruffleHog's Lob detector, through v3.96.0, matchestest_followed by 35 word characters — the exact shape of a Python test name — and Lob's API answers 403 for those candidates, which that version reads as "key is active, account just lacks billing". The finding comes backVerified: true, the action's--failfires, and the job exits 183.Recent examples: PR #2477 hit four of them (
test_prose_without_a_value_is_left_alone,test_empty_test_list_returns_400_not_500,test_request_id_header_is_not_duplicated,test_upstream_exception_keeps_its_detail), PR #2486 one (test_summary_entity_ids_are_deduplicated).This is not branch-specific —
mainfails the same way. It did on 2026-08-12, commit b24c616, ontest_the_covered_roots_all_actually_emit.mainhas been green since only because nothing merged after that happened to add a 40-character test name;tests/already contains 271 names of that length, but they sit in history rather than in any scanned diff.What Changed
.github/workflows/security.yml— added--exclude-detectors=Lobto the TruffleHogextra_args..pre-commit-config.yaml— same flag on the localtrufflehogpre-commit/pre-push hook, so it doesn't start reporting the same false positives once contributors upgrade their local binary.Both changes carry a comment explaining why the detector is off.
Additional Context
[a-f0-9]{35}and parses the 403 error code instead of trusting the status alone. That commit is on theirmain, but the newest release is v3.96.0 (2026-07-24) and the action pulls the released:latestimage, so we can't get the fix yet.@mainrather than a SHA, so upstream detector changes land in CI unannounced; and--results=verified,unknownmeans a detector that merely errors during verification fails the build, not just confirmed hits.Testing
Replayed the three previously failing scans with the exact CI arguments against the same image the workflow uses, all three now exit 0:
fix/harden-router-error-handling— was 4 findings, now 0fix/notification-accumulation— was 1, now 0b24c616c2onmain— was 1, now 0The pre-commit entry also runs clean, and the flag is accepted by older local binaries (verified on 3.93.3). This PR's own Security run is the live check.