> git annex assist
...
symlinkPointsToGitDir: symlink target points to git dir
remote: fatal: fsck error in pack objects
error: remote unpack failed: unpack-objects abnormal exit
IIUC, #git implemented something that uselessly breaks
#gitAnnex /
#DataLad compatibility on the remote side, amazing!
https://github.com/git/git/commit/a33fea0886cfa016d313d2bd66bdd08615bffbc9
Initial report:
@nobodyinperson @mih @chrysn unfortunately I will not be able to even look at this until Monday.
It seems to me that the git developers must be aware of git-annex. Therefore, I wonder why they didn't reach out to me. They didn't. That's all I have right now.
@nobodyinperson @mih @chrysn it's interesting that the CVE that triggered this change has to do with symlinks in .git/, not symlinks TO .git/.
@nobodyinperson @mih @chrysn
While it's understandable that someone encountering a symlink related security hole may want to throw out the baby with the bathwater, what the git devs have actually done here is to only throw out the baby. This change will not prevent the class of security hole that motivated it.
@nobodyinperson @mih @chrysn worth noting that this same patch also presumably breaks pushing legitimate symlinks with link text > 260 characters to a Windows host, assuming git on windows is built with a typical Windows PATH_MAX. Such a symlink is entirely legal on linux of course.
I wonder who reviewed this...
https://github.com/git/git/blame/a33fea0886cfa016d313d2bd66bdd08615bffbc9/fsck.c#L1239
My forum post at GitLab about this is now finally no longer hidden:
https://forum.gitlab.com/t/recent-git-v2-45-1-breaks-git-annex-compatibility/104909
also its PATH_MAX check has a fencepost error; PATH_MAX includes the trailing NUL, so the maximum symlink link target is PATH_MAX - 1
@joeyh OS+filesystem dependent PATH_MAX
in git seems a bit weird though, at least it makes sense to me you'd at least warn for >256 (_POSIX_PATH_MAX
).