Recent git v2.45.1 breaks git annex compatibility because of apparent fsck.symlinkPointsToGitDir=error on GitLab

Problem to solve

A setting on GitLab with git v2.45.1 (apparently fsck.symlinkPointsToGitDir=error on push/receive) breaks git annex (and thus DataLad) compatibility by rejecting commits containing symlinks pointing into the .git directory (a key design of git annex).

(Of course I am aware that GitLab dropped its own git annex support by not receiving annexed files anymore, but tracking metadata in the normal git-annex branch worked perfectly fine still until now.)

Steps to reproduce

• execute the following script:

  git init my-git-annex-repo
  cd my-git-annex-repo
  git annex init
  echo hi > README.md
  git annex add
  git commit -m "Add README"
  git remote add gitlab git@gitlab.com:nobodyinperson/my-git-annex-repo
  ls -l
  git push gitlab
  

• output:

  🐟 ❯ LC_ALL=C bash test.sh
  Initialized empty Git repository in /home/yann/code/git-annex-test/my-git-annex-repo/.git/
  init  ok
  (recording state in git...)
  add README.md 
  ok                                
  (recording state in git...)
  [main (root-commit) 3e9b3ca] Add README
   1 file changed, 1 insertion(+)
   create mode 120000 README.md
  total 4
  lrwxrwxrwx 1 yann users 184 May 21 13:33 README.md -> .git/annex/objects/k8/wf/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4.md/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4.md
  Enumerating objects: 3, done.
  Counting objects: 100% (3/3), done.
  Delta compression using up to 6 threads
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (3/3), 1.52 KiB | 1.52 MiB/s, done.
  Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
  remote: error: object b7260c7c4fe0839c70cd8f5371fa97a98d710cc5: symlinkPointsToGitDir: symlink target points to git dir
  remote: fatal: fsck error in pack objects
  error: remote unpack failed: unpack-objects abnormal exit
  To gitlab.com:nobodyinperson/my-git-annex-repo
   ! [remote rejected] main -> main (unpacker error)
  error: failed to push some refs to 'gitlab.com:nobodyinperson/my-git-annex-repo'
  

• push rejected by GitLab with error symlinkPointsToGitDir: symlink target points to git dir

Context

• This is probably related to Git v2.45.1 (April/May 2024), which is deployed at GitLab.com.
• This release contains a fix for a CVE about file:// urls and hardlinking problems.
• related git changeset: fsck: warn about symlink pointing inside a gitdir · git/git@a33fea0 · GitHub
• Apparently this is just a warning, so why does it reject the commit, then? Apparently GitLab has set fsck.symlinkPointsToGitDir=error to make fsck error out. None of the other forges (sourcehut, GitHub, Gitea, forgejo, …) seem to do this. Why does GitLab have this set?

Versions

Please select whether options apply, and add the version information.

• GitLab com SaaS

Versions

• GitLab: 17.1.0-pre e9764f6a1ae

Helpful resources

search the following, nothing related found:

• Before opening a new topic, make sure to search for keywords in the forum search
• Check the GitLab project for existing issues. If you encounter a bug, please create a bug report issue.
• Troubleshooting docs: Self-managed GitLab instances.

Same issue here. These are not only valid repositories but quite common too. I’m now having to hold off upgrading my self hosted instances because it isn’t clear this will still work there and I rely on git-annex working on those instances for production work.

gitlab appears to have the git config receive.fsckObjects set.

This problem could be avoided if gitlab also set receive.fsck.symlinkPointsToGitDir = ignore.

Running into this too, on company instance hosted by gitlab.com. Is there any workaround?

Workaround is to git annex unlock all files or using a different forge. Luckily, git annex sync|assist can sync many remotes, even if one fails.

This is also affecting us at my company, with a self-hosted GitLab on v17.0.1.

Is there any way admins of a hosted GitLab instance can control the receive.fsck.symlinkPointsToGitDir option?

Thanks for flagging, I’ve asked our teams. The problem is tracked in Set `fsck.symlinkPointsToGitDir=ignore` configuration (#6090) · Issues · GitLab.org / gitaly · GitLab and an MR has been created, reviewed and merged. It is not yet deployed to production (GitLab.com SaaS).

Regarding the question about GitLab enabling the check

We didn’t explicitly turn on the check. There was an issue in Git that lead the warning being upgraded to an error unintended. https://public-inbox.org/git/20240530081725.GH1949834@coredump.intra.peff.net/T/#t talks about this.

For future reports that sound like a bug, or block production, I’d recommend creating a bug report.

A git annex assist to a repo on GitLab.com now works for me again, seems to be fixed