Secret Leaks workflow fails on every new-branch push (6 of the last 30 runs)

Locate the Secret Leaks workflow and inspect its with: block and the script invocation that sets the scan range. Compare a new-branch push with a main push, then reproduce the workflow on a test branch. Done means new-branch pushes scan only their new commits, retain the current detector coverage, and no longer fail on the historical URL in scripts/convert_vq_diffusion_to_diffusers.py.

Describe the bug

The Secret Leaks workflow fails on every push that creates a new branch, in this repo and in every fork. It is 6 of the last 30 runs on huggingface/diffusers itself — cli-autooffload, minimax-h3-refactor, group-offload-auto-offload, minimax-h3, modular-docstring-configs-oneperline, and a dependabot branch. Pushes to main pass.

Every failure is the same two annotations:

scripts/convert_vq_diffusion_to_diffusers.py#L11
scripts/convert_vq_diffusion_to_diffusers.py#L20
Found unverified AzureSasToken result with HTML encoding

Why it only happens on new branches

The action picks its scan range from the push event. On a new branch github.event.before is all zeros, and the action's own script maps that to an empty base, which means "scan the whole history":

if [ "push" == "push" ]; then
    HEAD=<sha>
    if [ 0000000000000000000000000000000000000000 == "0000000000000000000000000000000000000000" ]; then
      BASE=""
    else
      BASE=0000000000000000000000000000000000000000
    fi
fi
...
docker run ... trufflehog git file:///tmp/ --since-commit ${BASE:-''} --branch ${HEAD:-''} --fail ...

From the logs, the difference is visible directly:

• failing run 30836004171 (new branch): BASE=""
• passing run 30833246954 (main): BASE=f83ba3b7cd758112a36d1c0d63fe6864295ea05b

So a push to main scans only the new commits, while a new branch rescans back to the first commit and reaches a file added in 2022.

The finding itself is real

Worth stating plainly, because it changes what the right fix is: this is not a scanner false positive. scripts/convert_vq_diffusion_to_diffusers.py documents a wget command whose URL carries a genuine Azure SAS token, with se=2030-05-31 and sp=r. It is third-party (Microsoft's VQ-Diffusion model hosting), read-only, and has been public in this repo since 2022, so the exposure is not this project's — but the detector is correct to flag it.

Two consequences:

1. The # trufflehog:ignore marker already on that line does not suppress it, because the match comes from the URL-encoded form (the annotation says "with HTML encoding") rather than the plain one.
2. Editing or removing the line would not fix the failures either, since the scan reaches it through history rather than through the working tree.

Suggested fix

Give the action an explicit base so branch pushes scan only their own commits, which is what the main path already does:

      with:
        base: ${{ github.event.repository.default_branch }}
        head: HEAD
        extra_args: --results=verified,unknown

Only the with: block changes — I have left the pinned uses: SHA out deliberately, since #14362 is bumping it.

That keeps --results=verified,unknown and the current detector coverage; it only stops re-scanning history that has already been scanned on main. If you would rather keep full-history scanning, the alternative is an exclude entry for that one path, though that is a wider hole.

I am happy to open the PR for whichever you prefer — I did not want to change CI configuration without asking first.

If this is already known

The workflow has been configured this way since #8430 in June 2024, so it is possible this is understood and tolerated. The reason I think it is still worth fixing: at 6 failures in 30 runs, a red Secret Leaks badge is the normal state for anyone pushing a branch, which is the condition under which a genuine future finding gets waved through. That risk is what makes it more than cosmetic.

Reproduction

Push any new branch to a fork or to this repo and watch the Secret Leaks workflow. It fails at the trufflehog step with exit code 183.

System Info

Not environment-specific; it is a CI configuration issue. Observed on main at 6f2010e8b.

Who can help?

Anyone maintaining CI for this repo.