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

comment

Browse source
This commit is contained in:
Joey Hess 2024-05-21 17:47:55 -04:00
parent aff6c12949
commit 5fb307f1c5
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 21 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

17
doc/todo/deal_with_git_fsck_symlinkPointsToGitDir.mdwn
View file

@ -24,20 +24,3 @@ configs.
Is it at all common to set `git config fetch.fsckObjects true` or Is it at all common to set `git config fetch.fsckObjects true` or
`git config receive.fsckObjects` true? `git config receive.fsckObjects` true?
> BTW, I have to mention that I'm deeply unhappy for git for making this
> change, with such a
> [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.
> --[[Joey]]

21
doc/todo/deal_with_git_fsck_symlinkPointsToGitDir/comment_1_0cbe5ed96c9fa9dea13bdf6b52243243._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2024-05-21T21:47:38Z"
content="""
BTW, I have to mention that I'm deeply unhappy for git for making this
change, with such a
[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.
"""]]