Findings With Empty Fields (Github Anomaly?)

[galiagante]

Description I though to contact you first about an issue I’ve seen pop up intermittently with a small number of private repos. When scanned with ‘gitleaks’ 8.x (I’m using 8.2.7, presently), the generated findings are missing elements. See screenshots below. This might indicate an unexpected edge case in a repo's structure logic that has not been accounted for, or some (new?) structural error in the repo's being accessed.

To Reproduce I am unable to offer a method to reproduce this behavior publicly, but I am able to do so reliably with the private repos in question. At this time, I have no evidence to suggest that the public/private status of a repo plays any role in the observed behavior.

Expected behavior Elements such as commit hash, commit message are expected to be present. In the majority of cases, this is the case, but failures are consistent-- no intermittent or arbitrary aspects of this issue have been observed.

Screenshots Unexpected structure as seen from the UI:

Note that normal single entry for a subordinate directory is instead showing multiple points along that same path. Upon manually inspecting the intervening directories, they appear to be empty except for a single entry leading the next directory down-stream.

Example of missing elements in a generated finding:

Basic Info (please complete the following information):

• OS: Various (tested on multiple Linux distros and versions
• Gitleaks Version: 8.2.7 (but was also recently observed in version 7.3 and 7.5)

**Additional This behavior has only been recently observed. I am not convinced the is a problem with 'gitleaks' per-se, but might represent anomalous behavior in Github that requires additional compensating logic. This speculation is supported by the observation that this issue appears to be occurring only with recent repo's that are being transferring in from other orgs or are being "recreated" from local sources. Repos with a longer history in our orgs (more than 30 day, at least) do not appear to be affected.

cc @zricethezav

[k0ral]

I've stumbled into the same issue, and in my case, this happens when a changeset includes a binary file diff: go-gitdiff fails to parse the specific format used by git log for binary diff, and the subsequent changeset from git log ends up producing a finding with empty fields.

Fixing the binary diff parsing effectively fixed the empty fields for me. Hopefully this covers also your instances of the issue.

[k0ral]

FYI there's another issue in go-gitdiff, related to empty name/email in patch headers, that can cause findings with empty fields as well: https://github.com/gitleaks/go-gitdiff/pull/2 .

[zricethezav]

@galiagante Is this still an issue using the most recent gitleaks version?

[zricethezav]

Going to close this issue due to inactivity. @galiagante feel free to re-open if this is still an issue.