{{ message }}
Allowlist huggingface-hub's http_backoff loop so Security audit stops failing - #9252
Merged
Conversation
… failing Security audit has been red on every main commit since fc325f4, on all three pip scan-packages legs, with a single un-baselined CRITICAL: C2 polling/beaconing loop detected huggingface-hub huggingface_hub/utils/_http.py L461: while True: sha256:b087631... No repo commit caused it. fc325f4 changed workflows and one test file, nothing that resolves a dependency. What moved is upstream: the resolved huggingface-hub came off the 0.x line, and 1.26.1, 1.27.0 and 1.28.0 all carry this loop while 0.36.2 does not. Reproduced locally against each of those versions, and the sha256 matches CI's byte for byte. The code is `http_backoff`: it counts nb_tries against max_retries, sleeps with exponential backoff between attempts, and raises once the budget is spent. A bounded retry, not a beacon. RE_C2_POLLING is `while True .* sleep .* requests\.` under re.DOTALL, which cannot tell those apart, so the file is allowlisted rather than the check weakened -- consistent with the 51 CRITICALs already reviewed this way, four of them this same check in this same package. Added with the scanner's own --write-baseline so the evidence_hash is computed by the code that will match it, then merged as a single entry rather than by regenerating: a full rewrite re-sorts the file and turns a one-entry review into a 731-line diff. Nothing else added or removed, asserted on both directions of the key set. Worth recording: this file now holds FOUR entries for this check, at L298, L461, L462 and L461 again, one per revision of the loop huggingface-hub has shipped. That is the mechanism working -- the key is digest-pinned, so every edit reopens the finding for review -- but it means a hub release touching those thirty lines turns Security audit red again. The new test says so, so the next one is read as upstream drift rather than a break. test_the_hf_backoff_suppression_is_narrow guards the part that actually matters about silencing a CRITICAL in a file that already speaks HTTP: every entry stays pinned to reviewed code, none are duplicated, and a beaconing loop appended to the same file under the same check produces a different key rather than inheriting the suppression. Three mutations checked red (drop the entries, strip the sha256 pin, duplicate an entry). Verified: scan of huggingface-hub 1.28.0 goes 1 CRITICAL to 0, exit 1 to 0. tests/security/test_scan_packages.py 123 passed.
for more information, see https://pre-commit.ci
This was referenced Aug 24, 2026
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.

Security audit has been red on every main commit since fc325f4, on all three
pip scan-packageslegs, with a single un-baselined CRITICAL:No repo commit caused it
fc325f4 changed workflows and one test file, nothing that resolves a dependency. What moved is upstream: the resolved huggingface-hub came off the 0.x line. Reproduced locally against each version, and the sha256 matches CI's byte for byte:
utils/_http.pyflaggedIt is a false positive
The code is
http_backoff: it countsnb_triesagainstmax_retries, sleeps with exponential backoff between attempts, and raises once the budget is spent. A bounded retry, not a beacon.RE_C2_POLLINGiswhile True .* sleep .* requests\.underre.DOTALL, which cannot tell those two shapes apart. So the file is allowlisted rather than the check weakened — consistent with the 51 CRITICALs already reviewed this way, four of them this same check in this same package.How the entry was produced
With the scanner's own
--write-baseline, so theevidence_hashis computed by the code that will match it, then merged as a single entry rather than by regenerating the file. A full rewrite re-sorts it and turns a one-entry review into a 731-line diff. Nothing else was added or removed; asserted on both directions of the key set. The diff is 8 lines.Worth knowing for next time
This file now holds four entries for this check — L298, L461, L462 and L461 again — one per revision of the loop huggingface-hub has shipped. That is the mechanism working as designed: the key is digest-pinned, so every edit reopens the finding and asks for a fresh review. The cost is that a hub release touching those thirty lines turns Security audit red again. The new test says so in place, so the next one gets read as upstream drift rather than a break.
Guard
test_the_hf_backoff_suppression_is_narrowcovers the part that actually matters about silencing a CRITICAL in a file that already speaks HTTP:sha256:present,evidence_hashexplicit),Three mutations confirmed red: drop the entries, strip the sha256 pin, duplicate an entry.
Verification
scan_packages.py huggingface-hub==1.28.0: 1 CRITICAL → 0, exit 1 → 0.tests/security/test_scan_packages.py: 123 passed.