Hi Johannes
On 27/05/2024 20:51, Johannes Schindelin wrote:
Hi Joey,
On Thu, 23 May 2024, Joey Hess wrote:
Junio C Hamano wrote:
- The extra check seems to have meant to target the symbolic links
that point at objects, refs, config, and anything _we_ care
about, as opposed to random garbage (from _our_ point of view)
files third-parties throw into .git/ directory. Would it have
made a better trade-off if we tried to make the check more
precise, only complaining about the things we care about (in
other words, what _we_ use)
I wondered about that possibility too. But it's not at all clear to
me how a symlink to .git/objects/foo risks any more security problem
to git than one to .git/annex/whatever, or indeed to /home/linus/.bashrc.
It risks more security problems because `.git/objects/??/*` is not
re-hashed when it is being used by Git. That's a very easy way to slip in
unwanted file contents.
What checks do we have in place to prevent git checking out blobs and
gitlinks to paths under .git/? I'd have thought we should be applying
the same restrictions to the target of symbolic links as we do to those.
And there is a good reason _not_ to write stuff inside the `.git/`
directory unless you happen to be, well, Git itself: Git makes no
guarantees whatsoever that you can write into that directory whatever you
want. A future Git version might even write a file `.git/annex`, breaking
`git-annex`' assumptions, and that'd be totally within the guarantees Git
makes.
This seems a bit harsh - many tools store their state under .git/ and I
think it makes sense for them to do so as it avoids creating untracked
files in the working copy. I would hope that we'd be considerate of
widely used tools such as 'git annex' when adding new paths under .git/
Best Wishes
Phillip
