Conversation

Notices

1. Embed this notice
   Yann Büchau :nixos: (nobodyinperson@fosstodon.org)'s status on Wednesday, 22-May-2024 17:07:22 JST Yann Büchau :nixos:

   • chrysn
   • see shy jo
   • Michael Hanke

   🍿

   > 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: #git implemented something that uselessly breaks :gitannex: #gitAnnex / :datalad: #DataLad compatibility on the remote side, amazing! 🤦

   https://github.com/git/git/commit/a33fea0886cfa016d313d2bd66bdd08615bffbc9

   Initial report:

   https://git-annex.branchable.com/forum/Strange_symlinkPointsToGitDir_error/#comment-12ed3e72e46de9b086da51455f20b26b

   @joeyh @mih @chrysn

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 22-May-2024 17:07:17 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • see shy jo

     @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).

   • Embed this notice
     see shy jo (joeyh@hachyderm.io)'s status on Wednesday, 22-May-2024 17:07:18 JST see shy jo

     in reply to

     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

   • Embed this notice
     see shy jo (joeyh@hachyderm.io)'s status on Wednesday, 22-May-2024 17:07:19 JST see shy jo

     in reply to

     • chrysn
     • Michael Hanke

     @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

   • Embed this notice
     see shy jo (joeyh@hachyderm.io)'s status on Wednesday, 22-May-2024 17:07:20 JST see shy jo

     in reply to

     • chrysn
     • Michael Hanke

     @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.

   • Embed this notice
     see shy jo (joeyh@hachyderm.io)'s status on Wednesday, 22-May-2024 17:07:21 JST see shy jo

     in reply to

     • chrysn
     • Michael Hanke

     @nobodyinperson @mih @chrysn it's interesting that the CVE that triggered this change has to do with symlinks in .git/, not symlinks TO .git/.

   • Embed this notice
     see shy jo (joeyh@hachyderm.io)'s status on Wednesday, 22-May-2024 17:07:22 JST see shy jo

     in reply to

     • chrysn
     • Michael Hanke

     @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.