hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

9.9K
active users

see shy jo

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

github.com/git/git/blame/a33fe

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