gitleaks / gitleaks

Protect and discover secrets using Gitleaks πŸ”‘

Home Page:https://gitleaks.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Gitleaks-docker crashes due to Git error: unknown option `staged'

segovia-no opened this issue Β· comments

Describe the bug
When using gitleaks-docker as a pre-commit hook, the execution of the hook will fail due to a Git error, which shows that there is no "staged" option for the git diff command.

To Reproduce

Create a git hook with pre-commit with this configuration in the .pre-commit-config.yaml file

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
      - id: gitleaks-docker
        name: gitleaks
        stages: [commit]
        args: ["-c", "./.gitleaks.toml"]

I'm using an additional .gitleaks.toml configuration file for gitleaks with this content

# This is an extension of GitLeaks configuration to detect MongoDB URI's
title = "Gitleaks MongoDB URI detection rule"

# Make this configuration file an extension of the base GitLeaks configuration.
[extend]
useDefault = true

[[rules]]
description = "MONGODB URI"
id = "mongodb-uri"
regex = '''mongodb\+srv:\/\/(.*):(.*)@(.*)'''
secretGroup = 1
tags = ["secrets"]
keywords = ["mongo", "mongodb", "uri"]

Install the hooks using this command
pre-commit install --hook-type pre-commit --hook-type commit-msg --hook-type pre-push

After staging any change, i use git commit, and then Gitleaks fails as shown below:

[INFO] Initializing environment for https://github.com/gitleaks/gitleaks.
gitleaks.................................................................Failed
- hook id: gitleaks-docker
- exit code: 1

β—‹
    β”‚β•²
    β”‚ β—‹
    β—‹ β–‘
    β–‘    gitleaks

7:46PM ERR [git] error: unknown option `staged'
7:46PM ERR [git] usage: git diff --no-index [<options>] <path> <path>

Expected behavior
Gitleaks scans for any leaked information as expected. Git hooks continues to execute normally.

Screenshots
None, same as "To reproduce" steps

Basic Info (please complete the following information):

  • OS: macOS Sonoma 14.1 - Apple Silicon M1 CPU
  • Gitleaks Version: 8.18.2

Additional context
Is the --staged option of Git deprecated? the synonym is the --cached option.

Maybe this line is the culprit?

"--staged", ".")

cc @zricethezav

I just ran into this issue and I think the error message is misleading. The actual cause in my case is that the repo is owned by my user, but the mount point in the container is owned by root; git rejects this directory, and the git diff command erroneously complains about "--staged".

Note: running "git diff --staged" locally in your repo probably works, whereas running it in a directory that is not a repo will yield the same error message.

Trying to run git log in this image, using the same docker command that pre-commit uses:

docker run -u 501:20 -v "$PWD:/src:rw,Z" --entrypoint git --workdir /src zricethezav/gitleaks log

(501:20 are my user and group id on the local machine) shows the actual problem:

fatal: detected dubious ownership in repository at '/src'
To add an exception for this directory, call:

	git config --global --add safe.directory /src

The suggested fix has already been applied in Dockerfile. Unfortunately, it does not work, because the user whose config it is added for is root, not the user that pre-commit runs the command as (in my case, 501:20).

A workaround that seems to succeed is to add an 'entry' to the gitleaks-docker hook which overrides the user setting that is passed by pre-commit:

- repo: https://github.com/zricethezav/gitleaks.git
    rev: v8.18.2
    hooks:
      - id: gitleaks-docker
        stages: [commit]
        entry: -u root:root zricethezav/gitleaks protect --verbose --redact --staged

Unfortunately, I also have to report that on my colleague's MacBook with essentially identical versions the hook works. So I am still looking for the underlying cause.

We have the same issue on multiple dev machines. The workaround from @herblet works so far, but an upstream fix would be highly appreciated.

I had the same issue while developing from my M1 macOS Sonoma 14.0, but the same configuration worked on my WSL2 instance in my windows machine. Implementing the workaround from @herblet worked for me on my mac.