]> git.ipfire.org Git - thirdparty/git.git/commit - fsck.c
fsck: warn about symlinked dotfiles we'll open with O_NOFOLLOW
authorJeff King <peff@peff.net>
Mon, 3 May 2021 20:43:25 +0000 (16:43 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 4 May 2021 02:52:02 +0000 (11:52 +0900)
commitbb6832d5529a75164acca7c0412657c96a9a5764
tree6e3a01b9c645e1eb356704e5b1dc10cd7878013d
parent801ed010bf13465bf67608beabbaa1ec2550204f
fsck: warn about symlinked dotfiles we'll open with O_NOFOLLOW

In the commits merged in via 204333b015 (Merge branch
'jk/open-dotgitx-with-nofollow', 2021-03-22), we stopped following
symbolic links for .gitattributes, .gitignore, and .mailmap files.

Let's teach fsck to warn that these symlinks are not going to do
anything. Note that this is just a warning, and won't block the objects
via transfer.fsckObjects, since there are reported to be cases of this
in the wild (and even once fixed, they will continue to exist in the
commit history of those projects, but are not particularly dangerous).

Note that we won't add these to the existing gitmodules block in the
fsck code. The logic for gitmodules is a bit more complicated, as we
also check the content of non-symlink instances we find. But for these
new files, there is no content check; we're just looking at the name and
mode of the tree entry (and we can avoid even the complicated name
checks in the common case that the mode doesn't indicate a symlink).

We can reuse the test helper function we defined for .gitmodules, though
(it needs some slight adjustments for the fsck error code, and because
we don't block these symlinks via verify_path()).

Note that I didn't explicitly test the transfer.fsckObjects case here
(nor does the existing .gitmodules test that it blocks a push). The
translation of fsck severities to outcomes is covered in general in
t5504.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck.c
fsck.h
t/t7450-bad-git-dotfiles.sh