Occasionally, the secret detection job on my project (on gitlab.com) fails with:
Couldn't run the gitleaks command: exit status 2 Gitleaks analysis failed: exit status 2
I will try to get time to create a minimal project to reproduce and file an issue, but in the meantime there are two things that I see as bugs:
The list of commits to scan is wrong
The git command to produce the list of commits is:
git log --left-right --cherry-pick --pretty=format:"%H" refs/remotes/origin/$CI_DEFAULT_BRANCH...refs/remotes/origin/$CI_COMMIT_REF_NAME
- Shouldn’t the commits be the ones on the current branch that are not on the default branch? I.e. shouldn’t it be
defaultBranch...currentBranch? (Two dots instead of three!). Otherwise commits on the default branch are also scanned from jobs running on the current branch.
--left-righthas no effect because
--pretty=format:"%H"deletes the left/right markings. Tracking the changes through history, it has never had an effect.
Handling of GIT_LENGTH is wrong
In the function
limitCommits in the secrets scanner (https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/gitleaks/gitleaks.go#L184) …
- It is blindly assumed that the list of commits passed is consecutive commits. This is not generally the case. Also: it is particularly not the case for how the scanner is currently used, where commits from both the default branch and the current branch is picked with the
- It is assumed that handling of
GIT_LENGTHis simply a matter of truncating the list of commits. How can this be right, when the list of commits can be any list of commits? Also – will there even be commits, that are unknown, when the list has been produced from a repository with git depth set – will
git logeven return commits that are not part of a shallow clone?