Git-secret: custom githook error: fatal: Not a git repository: '.git' or repository is broken. try running 'git init' or 'git clone'. abort.

[notjames]

at first glance, this appears to be a bug in git rev-parse --is-inside-work-tree used by git-secret in function _is_inside_git_tree but I'm still verifying. What I have so far is:

from outside the script, running strace, git rev-parse is supposed to recursively backward check the path until it finds a directory called .git. For some reason, within the script, it checks PWD and then when it finds no .git it hard fails without recursively back-checking the path. I'm not using symlinks (hard or soft) so why it just fails is not immediately understood. Here are the straces to show what I'm talking about:

within git-secret script:

 75 close(3)                                = 0                                                                                                                                      
 76 rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0                                                                                                                                 
 77 rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f7bd0f2c140}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0    
 78 getcwd("/path/to/stuff", 129) = 85                                                                         
 79 stat(".git", 0x7ffd5ff05870)            = -1 ENOENT (No such file or directory)                                                                                                  
 80 lstat(".git/HEAD", 0x7ffd5ff05720)      = -1 ENOENT (No such file or directory)                                                                                                  
 81 write(2, "fatal: Not a git repository: '.git'\n", 36) = 36                                                                                                                       
 82 exit_group(128)                         = ? 

From cli:

close(3)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f059c648140}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
getcwd("/path/to/stuff/dir1/dir2/dir3/", 129) = 85
stat("/path/to/stuff/dir1/dir2/dir3/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/path/to/stuff/dir1/dir2/dir3/.git", 0x7ffe11580bc0) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/dir2/dir3/.git/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/dir2/dir3/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
stat("/path/to/stuff/dir1/dir2/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/path/to/stuff/dir1/dir2/.git", 0x7ffe11580bc0) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/dir2/.git/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/dir2/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
stat("/path/to/stuff/dir1/", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/path/to/stuff/dir1/.git", 0x7ffe11580bc0) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/.git/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
lstat("/path/to/stuff/dir1/HEAD", 0x7ffe11580a70) = -1 ENOENT (No such file or directory)
stat("/path/to/stuff", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat("/path/to/stuff/.git", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat("/path/to/stuff/.git/HEAD", {st_mode=S_IFREG|0664, st_size=28, ...}) = 0
openat(AT_FDCWD, "/path/to/stuff/.git/HEAD", O_RDONLY) = 3
read(3, "ref: refs/heads/commit-hook\n", 255) = 28
read(3, "", 227)                        = 0
close(3)                                = 0

So you'll notice that rev-parse is checking to see if dir3 (and so on) is a directory and if it is then it recursively checks the parent directory to that just-checked directory, but the script version doesn't even perform that check. I'm not sure why, though. So, more to come.

Running the script from command line works perfectly. Only when running it from commit hook does it fail. the commit hook script:

#!/bin/bash
#
command -v git-secret >/dev/null 2>&1 || \
  {
    echo -e >&2 "\nThis repository is configured for Git Secret but 'git-secret' was not found on your path.
    If you no longer wish to use Git secret, remove this hook by deleting .git/hooks/pre-commit.\n"
    exit 2
  }

root_path="$(git rev-parse --show-toplevel)"

echo "ENSURING SHOULD-BE ENCRYPTED FILES ARE IN FACT STORED ENCRYPTED..."

while read -r p
do
  where="$(dirname "$p")"

  # skip the root dir
  # this will need to be tweaked potentially in the future
  # if secrets are ever stored here. For now, nothing like
  # that exists, so skipping.
  if [[ "$where" == "$root_path" ]]
  then
    continue
  fi

  if cd "$where"
  then
    echo "Verifying encrypted secrets in '$PWD'..."

    if git secret hide
    then
      echo -e "\t\tdone."
    else
      echo >&2 'Unable to hide secret data. Are you authorized to do this?'
      continue
    fi
  fi
done < <(find "$root_path" -type d -name .gitsecret)

[sobolevn]

@joshrabinowitz Could you please verify that this is still an issue?

[joshrabinowitz]

@sobolevn @notjames Can you confirm this is the issue?

Given:

• a git-secret repo set up (say in /full/path/.gitsecret, with git information in /full/path.git), and you are
• in a subdirectory /full/path/subdir, and
• use the shown commit hook

Observed result

• it gives an error instead of finding the .git and .gitsecret directories in the parent directory

Expected result:

• git hook works as expected

[joshrabinowitz]

Is this a git-secret issue?

Bug is described as 'this appears to be a bug in git rev-parse --is-inside-work-tree'.

Is there something git-secret should do differently to fix this problem?

@sobolevn @notjames

[notjames]

@sobolevn @joshrabinowitz We scrapped the commit hook in lieu of doing the work manually. We're considering re-using the commit hook to use git secret hide -m by default.

I will try and take a little time in the next day or two and see if there's a work around.

[joshrabinowitz]

hi @notjames is this still an issue?

[notjames]

Hi @joshrabinowitz -- it might still be an issue. Unfortunately, the project we were using for the repo (at the time of the issue creation) which required use of git-secret is now a dead project. I haven't had a chance to take a look at this since. I'm in favor of closing this issue for now. We may have another project coming up soon where we'll require using git-secret again. If this comes up again, I can re-open this issue and move forward with helping on it.