git 2.45.1 made git fsck warn if the repository contains a symlink to the git directory.
Strange symlinkPointsToGitDir error
https://fosstodon.org/@nobodyinperson/112478702707149836
While this has impacts such as pushing a git-annex repository to gitlab now failing, this todo is not concerned with that (because it's not something that can be fixed in git-annex).
What git-annex can do is configure fsck to not display this warning in a
git-annex repository and to allow fetch and receive to work even when
fetch.fsckObjects and receive.fsckObjects are set.
git config fsck.symlinkPointsToGitDir ignore
git config receive.fsck.symlinkPointsToGitDir ignore
git config fetch.fsck.symlinkPointsToGitDir ignore
It would be easy for git-annex init and upgrade to do this, but depending on the magnitude of breakage, which has not yet been assessed, git-annex may have to immediately make sure that all repositories it's used in get these configs.
Is it at all common to set git config fetch.fsckObjects true or
git config receive.fsckObjects true?
There is also potential breakage from git fsck now warning about symlink
targets that exceed PATH_MAX. On Windows, that is 260. A SHA512 key has a
symlink target of at least length 306. And even shorter keys, when located
in deep subdirectories, can have longer symlink targets than that. So
pushing to a bare repo on Windows could fail, for example. It even seems
likely this could affect pushing to Freebsd in some cases, since its
PATH_MAX is 1024 to Linux's 4096.
If git-annex wanted to also avoid this breakage, it could set:
git config fsck.symlinkTargetLength ignore
git config receive.fsck.symlinkTargetLength ignore
git config fetch.fsck.symlinkTargetLength ignore
Of course, that would not help when the bare repo is not git-annex initialized.
If a git-annex repo is checked out on Windows and has a longer symlink,
this will cause fsck to complain about it, even though git-annex will of
course use an adjusted unlocked branch and so the symlink won't actually be
followed. That seems like a good reason to set these configs. OTOH, there's
no benefit in doing it on Linux, unless some other OS has a longer
PATH_MAX than 4096 (Hurd?)
[Deleted this comment. I was annoyed and rightfully so, but I also misunderstood which security hole led them down this path.]
Note that there is an active patch set in git.git mailing list reverting many of the "defense in depth" patches, which seem to have had many other bugs.
I've suggested they also revert the parts of that patch set that cause these problems.
Will hold off on git-annex changes until the git situation stabalizes, and until I have free time to deal with it more.
Junio has now queued for git 2.45.2, coming early in June:
Revert "fsck: warn about symlink pointing inside a gitdir"
I don't know if it will be backported to the other affected git versions.
As well as removing the symlink to .git check, that also removes the symlink target too long check.
Also, git-remote-annex is affected by the same git clone check about hooks getting installed as git-lfs. That check is also going to be reverted. git-remote-annex contains a workaround, but it currently only checks for the specific git versions that added that check, so if any new git point releases don't revert that check it will need to update its version list.
Fixed git was released. All these versions fix it: v2.45.2 v2.39.5, v2.40.3, v2.41.2, v2.42.3, v2.43.5, and v2.44.2
That does leave the fsck.symlinkTargetLength as potentially still a problem on Windows, but I think I'll consider this closed and if that does actually lead to problems on windws we can revisit.