[Bug]: compile.sh amends user's global git config; fails if it can't

[kjkent]

What happened?

Running ./compile fails if the user's global git config is a symlink to a read-only filesystem, as it usually is in NixOS. I imagine this holds true for other situations in which a user's git config is read-only to that user.

Log:

λ ./compile.sh
error: could not lock config file /home/kjkent/.config/git/config: Read-only file system
[💥] Error 255 occurred in main shell [ at /home/kjkent/dev/armbian/lib/functions/logging/runners.sh:211
    run_host_command_logged_raw() --> lib/functions/logging/runners.sh:211
                    regular_git() --> lib/functions/general/git.sh:44
      git_ensure_safe_directory() --> lib/functions/general/git.sh:60
                           main() --> ./compile.sh:47
 ]

Here's the relevant code:

## lib/functions/general/git.sh:60
# workaround new limitations imposed by CVE-2022-24765 fix in git, otherwise  "fatal: unsafe repository"
function git_ensure_safe_directory() {
  if [[ -n "$(command -v git)" ]]; then
    local git_dir="$1"
    if [[ -e "$1/.git" ]]; then
      display_alert "git: Marking all directories as safe, which should include" "$git_dir" "debug"
      git config --global --get safe.directory "$1" > /dev/null || regular_git config --global --add safe.directory "$1"
    fi
  else
    display_alert "git not installed" "a true wonder how you got this far without git - it will be installed for you" "warn"
  fi
}

There is that call to alert, but, as seen in the output above, there's no console output other than the error.

I'm not knowledgeable about the build process enough to understand why the compile script, for a Dockerised build, needs to access a git config file in a parent directory either not as me, or not owned by me; however, silently altering global git config in order to bypass a CVE-related security feature specifically to prevent this does pose the question of its appropriateness. It feels like sketchy behaviour, even when it's for benign reasons as I'm sure it is here.

(As an aside, the shell.nix in the repo root suggests NixOS compatibility, but this and (moreso) #7052) are blockers for usage on these systems -- though non-NixOS systems using Nix as a package manager would probably work fine.

How to reproduce?

1. Have global user git config (eg ~/.gitconfig) be a symlink to a file on a read-only filesystem.
2. Run ./compile in repo directory.

Branch

v25.02

On which host OS are you running the build script and observing this problem?

NixOS 24.11

Are you building on Windows WSL2?

• Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Hey @kjkent !

Looks like it's your first time interacting with Armbian here on GitHub.

Welcome and thank you for taking the time to report an issue ❤️.

Don't forget to star ⭐ the repo.

[github-actions]

Jira ticket: AR-2624

[igorpecovnik]

It feels like sketchy behaviour

Indeed. This is known dirty workaround, but have to scratch my head to understand why we had to use this. IIRC it was due to some changes introduced by Git client. We tried to address this several times, but then if fail out of urgent things.

[kjkent]

Makes sense. Repos not being owned by the current user might be more of an issue on Windows, as that appeared to be a common thread when I searched this. It's not an issue I've encountered on Linux (as far as I remember!)