mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2024-05-27 22:44:35 -04:00
parent 0975e792ea
commit c2483f6e6d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 22 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
doc/todo/deal_with_git_fsck_symlinkPointsToGitDir/comment_1_0cbe5ed96c9fa9dea13bdf6b52243243._comment
View file

@ -3,19 +3,6 @@
subject="""comment 1""" subject="""comment 1"""
date="2024-05-21T21:47:38Z" date="2024-05-21T21:47:38Z"
content=""" content="""
BTW, I have to mention that I'm deeply unhappy for git for making this [Deleted this comment. I was annoyed and rightfully so, but I also
change, with such a misunderstood which security hole led them down this path.]
[weak justification](https://github.com/git/git/commit/a33fea0886cfa016d313d2bd66bdd08615bffbc9),
and so little care for breakage.
The change came after a security fix which involved symlinks and
`.git/objects`, but that was a symlink *inside* `.git/objects`,
which is entirely different than a symlink pointing into the
`.git` directory.
While it's understandable that someone encountering a
symlink related security hole may want to throw out the baby with the
bathwater, what they have actually done here is to only throw out the
baby. This change will not prevent the class of security hole that
motivated it.
"""]] """]]

20
doc/todo/deal_with_git_fsck_symlinkPointsToGitDir/comment_3_927812cb2d4a1789ba842c1fa55df13e._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2024-05-28T02:39:52Z"
content="""
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.
Currently, the fsck.symlinkTargetLength check has not been reverted,
so might want to still do something about that.
Also, git-remote-annex is affected by the same git clone check about hooks
getting installed as git-lfs. That check is also part of the reversion set.
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.
"""]]