Secrets detection fails when default branch has unrelated history
Summary
Secret detection will exit with error ERR fatal: ambiguous argument
when $CI_DEFAULT_BRANCH
is unrelated.
Steps to reproduce
# git init secret-detection-bug -b master && cd secret-detection-bug/
# git remote add origin git@gitlab.com:group/subgroup/secret-detection-bug.git
# for i in {1..5};do echo test${i} >> testfile.txt; git add testfile.txt; git commit -m "commit #${i} on master" ;done
# cat >.gitlab-ci.yml <<EOL
include:
- template: Security/Secret-Detection.gitlab-ci.yml
variables:
SECURE_LOG_LEVEL: "debug"
EOL
# git add .gitlab-ci.yaml; git commit -m "enable Secret Detection"
# git push origin master
### Creating unrelated branch
# git init secret-detection-bug2 -b gcs && cd secret-detection-bug2/
# git remote add origin git@gitlab.com:group/subgroup/secret-detection-bug.git
# for i in {1..5};do echo test${i} >> testfile.txt; git add testfile.txt; git commit -m "commit #${i} on gcs" ;done
# cat >.gitlab-ci.yml <<EOL
include:
- template: Security/Secret-Detection.gitlab-ci.yml
variables:
SECURE_LOG_LEVEL: "debug"
EOL
# git add .gitlab-ci.yaml; git commit -m "enable Secret Detection"
# git push origin gcs
The secret-detection job that starts by the push event on gcs
branch will fail.
Example Project
https://gitlab.com/gitlab-gold/kateg/secret-detection-bug/-/jobs/2055143176
What is the current bug behavior?
The secret-detection job that starts by the push event on gcs
branch will fail.
What is the expected correct behavior?
The secret-detection job that starts by the push event on gcs
branch should pass.
Relevant logs and/or screenshots
[INFO] [secrets] [2022-02-04T14:08:47Z] ▶ 2:08PM ERR fatal: ambiguous argument '27b8c90e6a8fa1114ee2e184aa070ff5d302c61f^..6206b23445155b547a79ea6294b79f55c0bc2082': unknown revision or path not in the working tree.
Output of checks
This bug happens on GitLab.com
Possible fixes
Do not include parent commit into the scan by removing ^
here. This fix has a drawback, however. The number of commits gitleaks has to scan will grow overtime indefinitely if default branch stays unrelated.
An alternative solution will be documenting this caveat in the Troubleshooting section and advise the customers to always make sure the the their repo's default branch is related to the branch where secret detection job is running. Created a Docs MR for this: !79959 (merged)