* [PATCH v2 1/8] fsck_tree(): fix shadowed variable
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 2/8] fsck_tree(): wrap some long lines Jeff King
` (8 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
Commit b2f2039c2b (fsck: accept an oid instead of a "struct tree" for
fsck_tree(), 2019-10-18) introduced a new "oid" parameter to
fsck_tree(), and we pass it to the report() function when we find
problems. However, that is shadowed within the tree-walking loop by the
existing "oid" variable which we use to store the oid of each tree
entry. As a result, we may report the wrong oid for some problems we
detect within the loop (the entry oid, instead of the tree oid).
Our tests didn't catch this because they checked only that we found the
expected fsck problem, not that it was attached to the correct object.
Let's rename both variables in the function to avoid confusion. This
makes the diff a little noisy (e.g., all of the report() calls outside
the loop were already correct but need to be touched), but makes sure we
catch all cases and will avoid similar confusion in the future.
Note that our test change removes the comment about translation. It was
arguably confusing since 674ba34038 (fsck: mark strings for translation,
2018-11-10); we wouldn't translate gitmodulesSymlink, but it did get
removed by GETTEXT_POISON because that feature eats embedded
%s characters. But certainly after this patch, when we look for the
"tree %s: %s" format, we could get foiled by translation.
Signed-off-by: Jeff King <peff@peff.net>
---
fsck.c | 40 +++++++++++++++++++-------------------
t/t7415-submodule-names.sh | 8 ++++----
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/fsck.c b/fsck.c
index f82e2fe9e3..46a108839f 100644
--- a/fsck.c
+++ b/fsck.c
@@ -633,7 +633,7 @@ static int verify_ordered(unsigned mode1, const char *name1,
return c1 < c2 ? 0 : TREE_UNORDERED;
}
-static int fsck_tree(const struct object_id *oid,
+static int fsck_tree(const struct object_id *tree_oid,
const char *buffer, unsigned long size,
struct fsck_options *options)
{
@@ -654,7 +654,7 @@ static int fsck_tree(const struct object_id *oid,
struct name_stack df_dup_candidates = { NULL };
if (init_tree_desc_gently(&desc, buffer, size)) {
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
return retval;
}
@@ -664,11 +664,11 @@ static int fsck_tree(const struct object_id *oid,
while (desc.size) {
unsigned short mode;
const char *name, *backslash;
- const struct object_id *oid;
+ const struct object_id *entry_oid;
- oid = tree_entry_extract(&desc, &name, &mode);
+ entry_oid = tree_entry_extract(&desc, &name, &mode);
- has_null_sha1 |= is_null_oid(oid);
+ has_null_sha1 |= is_null_oid(entry_oid);
has_full_path |= !!strchr(name, '/');
has_empty_name |= !*name;
has_dot |= !strcmp(name, ".");
@@ -678,10 +678,10 @@ static int fsck_tree(const struct object_id *oid,
if (is_hfs_dotgitmodules(name) || is_ntfs_dotgitmodules(name)) {
if (!S_ISLNK(mode))
- oidset_insert(&gitmodules_found, oid);
+ oidset_insert(&gitmodules_found, entry_oid);
else
retval += report(options,
- oid, OBJ_TREE,
+ tree_oid, OBJ_TREE,
FSCK_MSG_GITMODULES_SYMLINK,
".gitmodules is a symbolic link");
}
@@ -692,9 +692,9 @@ static int fsck_tree(const struct object_id *oid,
has_dotgit |= is_ntfs_dotgit(backslash);
if (is_ntfs_dotgitmodules(backslash)) {
if (!S_ISLNK(mode))
- oidset_insert(&gitmodules_found, oid);
+ oidset_insert(&gitmodules_found, entry_oid);
else
- retval += report(options, oid, OBJ_TREE,
+ retval += report(options, tree_oid, OBJ_TREE,
FSCK_MSG_GITMODULES_SYMLINK,
".gitmodules is a symbolic link");
}
@@ -703,7 +703,7 @@ static int fsck_tree(const struct object_id *oid,
}
if (update_tree_entry_gently(&desc)) {
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
break;
}
@@ -751,25 +751,25 @@ static int fsck_tree(const struct object_id *oid,
name_stack_clear(&df_dup_candidates);
if (has_null_sha1)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_NULL_SHA1, "contains entries pointing to null sha1");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_NULL_SHA1, "contains entries pointing to null sha1");
if (has_full_path)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_FULL_PATHNAME, "contains full pathnames");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_FULL_PATHNAME, "contains full pathnames");
if (has_empty_name)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_EMPTY_NAME, "contains empty pathname");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_EMPTY_NAME, "contains empty pathname");
if (has_dot)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_HAS_DOT, "contains '.'");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOT, "contains '.'");
if (has_dotdot)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_HAS_DOTDOT, "contains '..'");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOTDOT, "contains '..'");
if (has_dotgit)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_HAS_DOTGIT, "contains '.git'");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOTGIT, "contains '.git'");
if (has_zero_pad)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_ZERO_PADDED_FILEMODE, "contains zero-padded file modes");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_ZERO_PADDED_FILEMODE, "contains zero-padded file modes");
if (has_bad_modes)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_BAD_FILEMODE, "contains bad file modes");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_FILEMODE, "contains bad file modes");
if (has_dup_entries)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_DUPLICATE_ENTRIES, "contains duplicate file entries");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_DUPLICATE_ENTRIES, "contains duplicate file entries");
if (not_properly_sorted)
- retval += report(options, oid, OBJ_TREE, FSCK_MSG_TREE_NOT_SORTED, "not properly sorted");
+ retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_TREE_NOT_SORTED, "not properly sorted");
return retval;
}
diff --git a/t/t7415-submodule-names.sh b/t/t7415-submodule-names.sh
index f70368bc2e..d1781ef10c 100755
--- a/t/t7415-submodule-names.sh
+++ b/t/t7415-submodule-names.sh
@@ -148,13 +148,13 @@ test_expect_success 'fsck detects symlinked .gitmodules file' '
{
printf "100644 blob $content\t$tricky\n" &&
printf "120000 blob $target\t.gitmodules\n"
- } | git mktree &&
+ } >bad-tree &&
+ tree=$(git mktree <bad-tree) &&
# Check not only that we fail, but that it is due to the
- # symlink detector; this grep string comes from the config
- # variable name and will not be translated.
+ # symlink detector
test_must_fail git fsck 2>output &&
- test_i18ngrep gitmodulesSymlink output
+ test_i18ngrep "tree $tree: gitmodulesSymlink" output
)
'
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 2/8] fsck_tree(): wrap some long lines
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
2020-10-05 12:16 ` [PATCH v2 1/8] fsck_tree(): fix shadowed variable Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 3/8] t7415: rename to expand scope Jeff King
` (7 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
Many calls to report() in fsck_tree() are kept on a single line and are
quite long. Most were pretty big to begin with, but have gotten even
longer over the years as we've added more parameters. Let's accept the
churn of wrapping them in order to conform to our usual line limits.
Signed-off-by: Jeff King <peff@peff.net>
---
fsck.c | 48 ++++++++++++++++++++++++++++++++++++------------
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/fsck.c b/fsck.c
index 46a108839f..024810139b 100644
--- a/fsck.c
+++ b/fsck.c
@@ -654,7 +654,9 @@ static int fsck_tree(const struct object_id *tree_oid,
struct name_stack df_dup_candidates = { NULL };
if (init_tree_desc_gently(&desc, buffer, size)) {
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_BAD_TREE,
+ "cannot be parsed as a tree");
return retval;
}
@@ -703,7 +705,9 @@ static int fsck_tree(const struct object_id *tree_oid,
}
if (update_tree_entry_gently(&desc)) {
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_BAD_TREE,
+ "cannot be parsed as a tree");
break;
}
@@ -751,25 +755,45 @@ static int fsck_tree(const struct object_id *tree_oid,
name_stack_clear(&df_dup_candidates);
if (has_null_sha1)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_NULL_SHA1, "contains entries pointing to null sha1");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_NULL_SHA1,
+ "contains entries pointing to null sha1");
if (has_full_path)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_FULL_PATHNAME, "contains full pathnames");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_FULL_PATHNAME,
+ "contains full pathnames");
if (has_empty_name)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_EMPTY_NAME, "contains empty pathname");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_EMPTY_NAME,
+ "contains empty pathname");
if (has_dot)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOT, "contains '.'");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_HAS_DOT,
+ "contains '.'");
if (has_dotdot)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOTDOT, "contains '..'");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_HAS_DOTDOT,
+ "contains '..'");
if (has_dotgit)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_HAS_DOTGIT, "contains '.git'");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_HAS_DOTGIT,
+ "contains '.git'");
if (has_zero_pad)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_ZERO_PADDED_FILEMODE, "contains zero-padded file modes");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_ZERO_PADDED_FILEMODE,
+ "contains zero-padded file modes");
if (has_bad_modes)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_BAD_FILEMODE, "contains bad file modes");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_BAD_FILEMODE,
+ "contains bad file modes");
if (has_dup_entries)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_DUPLICATE_ENTRIES, "contains duplicate file entries");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_DUPLICATE_ENTRIES,
+ "contains duplicate file entries");
if (not_properly_sorted)
- retval += report(options, tree_oid, OBJ_TREE, FSCK_MSG_TREE_NOT_SORTED, "not properly sorted");
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_TREE_NOT_SORTED,
+ "not properly sorted");
return retval;
}
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 3/8] t7415: rename to expand scope
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
2020-10-05 12:16 ` [PATCH v2 1/8] fsck_tree(): fix shadowed variable Jeff King
2020-10-05 12:16 ` [PATCH v2 2/8] fsck_tree(): wrap some long lines Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 4/8] t7450: test verify_path() handling of gitmodules Jeff King
` (6 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
This script has already expanded beyond its original intent of ".. in
submodule names" to include other malicious submodule bits. Let's update
the name and description to reflect that, as well as the fact that we'll
soon be adding similar tests for other meta-files (.gitattributes, etc).
We'll also renumber it to move it out of the group of submodule-specific
tests.
Signed-off-by: Jeff King <peff@peff.net>
---
...ubmodule-names.sh => t7450-bad-dotgitx-files.sh} | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
rename t/{t7415-submodule-names.sh => t7450-bad-dotgitx-files.sh} (95%)
diff --git a/t/t7415-submodule-names.sh b/t/t7450-bad-dotgitx-files.sh
similarity index 95%
rename from t/t7415-submodule-names.sh
rename to t/t7450-bad-dotgitx-files.sh
index d1781ef10c..fb28539948 100755
--- a/t/t7415-submodule-names.sh
+++ b/t/t7450-bad-dotgitx-files.sh
@@ -1,9 +1,16 @@
#!/bin/sh
-test_description='check handling of .. in submodule names
+test_description='check forbidden or malicious patterns in .git* files
-Exercise the name-checking function on a variety of names, and then give a
-real-world setup that confirms we catch this in practice.
+Such as:
+
+ - presence of .. in submodule names;
+ Exercise the name-checking function on a variety of names, and then give a
+ real-world setup that confirms we catch this in practice.
+
+ - nested submodule names
+
+ - symlinked .gitmodules, etc
'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-pack.sh
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 4/8] t7450: test verify_path() handling of gitmodules
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (2 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 3/8] t7415: rename to expand scope Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 5/8] t7450: test .gitmodules symlink matching against obscured names Jeff King
` (5 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
Commit 10ecfa7649 (verify_path: disallow symlinks in .gitmodules,
2018-05-04) made it impossible to load a symlink .gitmodules file into
the index. However, there are no tests of this behavior. Let's make sure
this case is covered. We can easily reuse the test setup created by
the matching b7b1fca175 (fsck: complain when .gitmodules is a symlink,
2018-05-04).
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7450-bad-dotgitx-files.sh | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/t/t7450-bad-dotgitx-files.sh b/t/t7450-bad-dotgitx-files.sh
index fb28539948..8bfd32b10a 100755
--- a/t/t7450-bad-dotgitx-files.sh
+++ b/t/t7450-bad-dotgitx-files.sh
@@ -139,7 +139,7 @@ test_expect_success 'index-pack --strict works for non-repo pack' '
grep gitmodulesName output
'
-test_expect_success 'fsck detects symlinked .gitmodules file' '
+test_expect_success 'set up repo with symlinked .gitmodules file' '
git init symlink &&
(
cd symlink &&
@@ -155,8 +155,14 @@ test_expect_success 'fsck detects symlinked .gitmodules file' '
{
printf "100644 blob $content\t$tricky\n" &&
printf "120000 blob $target\t.gitmodules\n"
- } >bad-tree &&
- tree=$(git mktree <bad-tree) &&
+ } >bad-tree
+ ) &&
+ tree=$(git -C symlink mktree <symlink/bad-tree)
+'
+
+test_expect_success 'fsck detects symlinked .gitmodules file' '
+ (
+ cd symlink &&
# Check not only that we fail, but that it is due to the
# symlink detector
@@ -165,6 +171,13 @@ test_expect_success 'fsck detects symlinked .gitmodules file' '
)
'
+test_expect_success 'refuse to load symlinked .gitmodules into index' '
+ test_must_fail git -C symlink read-tree $tree 2>err &&
+ test_i18ngrep "invalid path.*gitmodules" err &&
+ git -C symlink ls-files >out &&
+ test_must_be_empty out
+'
+
test_expect_success 'fsck detects non-blob .gitmodules' '
git init non-blob &&
(
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 5/8] t7450: test .gitmodules symlink matching against obscured names
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (3 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 4/8] t7450: test verify_path() handling of gitmodules Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 6/8] t0060: test obscured .gitattributes and .gitignore matching Jeff King
` (4 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
In t7450 we check that both verify_path() and fsck catch malformed
.gitmodules entries in trees. However, we don't check that we catch
filesystem-equivalent forms of these (e.g., ".GITMOD~1" on Windows).
Our name-matching functions are exercised well in t0060, but there's
nothing to test that we correctly call the matching functions from the
actual fsck and verify_path() code.
So instead of testing just .gitmodules, let's repeat our tests for a few
basic cases. We don't need to be exhaustive here (t0060 handles that),
but just make sure we hit one name of each type.
Besides pushing the tests into a function that takes the path as a
parameter, we'll need to do a few things:
- adjust the directory name to accommodate the tests running multiple
times
- set core.protecthfs for index checks. Fsck always protects all types
by default, but we want to be able to exercise the HFS routines on
every system. Note that core.protectntfs is already the default
these days, but it doesn't hurt to explicitly label our need for it.
- we'll also take the filename ("gitmodules") as a parameter. All
calls use the same name for now, but a future patch will extend this
to handle other .gitfoo files. Note that our fake-content symlink
destination is somewhat .gitmodules specific. But it isn't necessary
for other files (which don't do a content check). And it happens to
be a valid attribute and ignore file anyway.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7450-bad-dotgitx-files.sh | 91 +++++++++++++++++++++---------------
1 file changed, 53 insertions(+), 38 deletions(-)
diff --git a/t/t7450-bad-dotgitx-files.sh b/t/t7450-bad-dotgitx-files.sh
index 8bfd32b10a..0cd0f71c39 100755
--- a/t/t7450-bad-dotgitx-files.sh
+++ b/t/t7450-bad-dotgitx-files.sh
@@ -139,44 +139,59 @@ test_expect_success 'index-pack --strict works for non-repo pack' '
grep gitmodulesName output
'
-test_expect_success 'set up repo with symlinked .gitmodules file' '
- git init symlink &&
- (
- cd symlink &&
-
- # Make the tree directly to avoid index restrictions.
- #
- # Because symlinks store the target as a blob, choose
- # a pathname that could be parsed as a .gitmodules file
- # to trick naive non-symlink-aware checking.
- tricky="[foo]bar=true" &&
- content=$(git hash-object -w ../.gitmodules) &&
- target=$(printf "$tricky" | git hash-object -w --stdin) &&
- {
- printf "100644 blob $content\t$tricky\n" &&
- printf "120000 blob $target\t.gitmodules\n"
- } >bad-tree
- ) &&
- tree=$(git -C symlink mktree <symlink/bad-tree)
-'
-
-test_expect_success 'fsck detects symlinked .gitmodules file' '
- (
- cd symlink &&
-
- # Check not only that we fail, but that it is due to the
- # symlink detector
- test_must_fail git fsck 2>output &&
- test_i18ngrep "tree $tree: gitmodulesSymlink" output
- )
-'
-
-test_expect_success 'refuse to load symlinked .gitmodules into index' '
- test_must_fail git -C symlink read-tree $tree 2>err &&
- test_i18ngrep "invalid path.*gitmodules" err &&
- git -C symlink ls-files >out &&
- test_must_be_empty out
-'
+check_forbidden_symlink () {
+ name=$1
+ type=$2
+ path=$3
+ dir=symlink-$name-$type
+
+ test_expect_success "set up repo with symlinked $name ($type)" '
+ git init $dir &&
+ (
+ cd $dir &&
+
+ # Make the tree directly to avoid index restrictions.
+ #
+ # Because symlinks store the target as a blob, choose
+ # a pathname that could be parsed as a .gitmodules file
+ # to trick naive non-symlink-aware checking.
+ tricky="[foo]bar=true" &&
+ content=$(git hash-object -w ../.gitmodules) &&
+ target=$(printf "$tricky" | git hash-object -w --stdin) &&
+ {
+ printf "100644 blob $content\t$tricky\n" &&
+ printf "120000 blob $target\t$path\n"
+ } >bad-tree
+ ) &&
+ tree=$(git -C $dir mktree <$dir/bad-tree)
+ '
+
+ test_expect_success "fsck detects symlinked $name ($type)" '
+ (
+ cd $dir &&
+
+ # Check not only that we fail, but that it is due to the
+ # symlink detector
+ test_must_fail git fsck 2>output &&
+ test_i18ngrep "tree $tree: ${name}Symlink" output
+ )
+ '
+
+ test_expect_success "refuse to load symlinked $name into index ($type)" '
+ test_must_fail \
+ git -C $dir \
+ -c core.protectntfs \
+ -c core.protecthfs \
+ read-tree $tree 2>err &&
+ test_i18ngrep "invalid path.*$name" err &&
+ git -C $dir ls-files -s >out &&
+ test_must_be_empty out
+ '
+}
+
+check_forbidden_symlink gitmodules vanilla .gitmodules
+check_forbidden_symlink gitmodules ntfs ".gitmodules ."
+check_forbidden_symlink gitmodules hfs ".${u200c}gitmodules"
test_expect_success 'fsck detects non-blob .gitmodules' '
git init non-blob &&
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 6/8] t0060: test obscured .gitattributes and .gitignore matching
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (4 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 5/8] t7450: test .gitmodules symlink matching against obscured names Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore Jeff King
` (3 subsequent siblings)
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
We have tests that cover various filesystem-specific spellings of
".gitmodules", because we need to reliably identify that path for some
security checks. These are from dc2d9ba318 (is_{hfs,ntfs}_dotgitmodules:
add tests, 2018-05-12), with the actual code coming from e7cb0b4455
(is_ntfs_dotgit: match other .git files, 2018-05-11) and 0fc333ba20
(is_hfs_dotgit: match other .git files, 2018-05-02).
Those latter two commits also added similar matching functions for
.gitattributes and .gitignore. These ended up not being used in the
final series, and are currently dead code. But in preparation for them
being used, let's make sure they actually work by throwing a few basic
checks at them.
I didn't bother with the whole battery of tests that we cover for
.gitmodules. These functions are all based on the same generic matcher,
so it's sufficient to test most of the corner cases just once.
Note that the ntfs magic prefix names in the tests come from the
algorithm described in e7cb0b4455 (and are different for each file).
Signed-off-by: Jeff King <peff@peff.net>
---
t/helper/test-path-utils.c | 41 ++++++++++++++++++++++++++------------
t/t0060-path-utils.sh | 20 +++++++++++++++++++
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/t/helper/test-path-utils.c b/t/helper/test-path-utils.c
index 313a153209..732372b97f 100644
--- a/t/helper/test-path-utils.c
+++ b/t/helper/test-path-utils.c
@@ -172,9 +172,22 @@ static struct test_data dirname_data[] = {
{ NULL, NULL }
};
-static int is_dotgitmodules(const char *path)
+static int check_dotgitx(const char *x, const char **argv,
+ int (*is_hfs)(const char *),
+ int (*is_ntfs)(const char *))
{
- return is_hfs_dotgitmodules(path) || is_ntfs_dotgitmodules(path);
+ int res = 0, expect = 1;
+ for (; *argv; argv++) {
+ if (!strcmp("--not", *argv))
+ expect = !expect;
+ else if (expect != (is_hfs(*argv) || is_ntfs(*argv)))
+ res = error("'%s' is %s.git%s", *argv,
+ expect ? "not " : "", x);
+ else
+ fprintf(stderr, "ok: '%s' is %s.git%s\n",
+ *argv, expect ? "" : "not ", x);
+ }
+ return !!res;
}
static int cmp_by_st_size(const void *a, const void *b)
@@ -382,17 +395,19 @@ int cmd__path_utils(int argc, const char **argv)
return test_function(dirname_data, posix_dirname, argv[1]);
if (argc > 2 && !strcmp(argv[1], "is_dotgitmodules")) {
- int res = 0, expect = 1, i;
- for (i = 2; i < argc; i++)
- if (!strcmp("--not", argv[i]))
- expect = !expect;
- else if (expect != is_dotgitmodules(argv[i]))
- res = error("'%s' is %s.gitmodules", argv[i],
- expect ? "not " : "");
- else
- fprintf(stderr, "ok: '%s' is %s.gitmodules\n",
- argv[i], expect ? "" : "not ");
- return !!res;
+ return check_dotgitx("modules", argv + 2,
+ is_hfs_dotgitmodules,
+ is_ntfs_dotgitmodules);
+ }
+ if (argc > 2 && !strcmp(argv[1], "is_dotgitignore")) {
+ return check_dotgitx("ignore", argv + 2,
+ is_hfs_dotgitignore,
+ is_ntfs_dotgitignore);
+ }
+ if (argc > 2 && !strcmp(argv[1], "is_dotgitattributes")) {
+ return check_dotgitx("attributes", argv + 2,
+ is_hfs_dotgitattributes,
+ is_ntfs_dotgitattributes);
}
if (argc > 2 && !strcmp(argv[1], "file-size")) {
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 56db5c8aba..b2e3cf3f4c 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -468,6 +468,26 @@ test_expect_success 'match .gitmodules' '
.gitmodules,:\$DATA
'
+test_expect_success 'match .gitattributes' '
+ test-tool path-utils is_dotgitattributes \
+ .gitattributes \
+ .git${u200c}attributes \
+ .Gitattributes \
+ .gitattributeS \
+ GITATT~1 \
+ GI7D29~1
+'
+
+test_expect_success 'match .gitignore' '
+ test-tool path-utils is_dotgitignore \
+ .gitignore \
+ .git${u200c}ignore \
+ .Gitignore \
+ .gitignorE \
+ GITIGN~1 \
+ GI250A~1
+'
+
test_expect_success MINGW 'is_valid_path() on Windows' '
test-tool path-utils is_valid_path \
win32 \
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (5 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 6/8] t0060: test obscured .gitattributes and .gitignore matching Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-27 3:35 ` Jonathan Nieder
2020-10-05 12:16 ` [PATCH v2 8/8] fsck: complain when .gitattributes or .gitignore is a symlink Jeff King
` (2 subsequent siblings)
9 siblings, 1 reply; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
In commit 10ecfa7649 (verify_path: disallow symlinks in .gitmodules,
2018-05-04) we made it impossible to load a .gitmodules file that's a
symlink into the index. The security reasons for doing so are described
there. We also discussed forbidding symlinks of other .git files as part
of that fix, but the tradeoff was less compelling:
1. Unlike .gitmodules, the other files don't have content-level fsck
checks. So an attacker using symlinks to evade those checks isn't a
problem.
2. Unlike .gitmodules, Git will never write .gitignore or
.gitattributes itself, making it much less likely to use them to
write outside the repo. They could be used for out-of-repo reads,
however.
3. The .gitmodules change was part of a critical bug-fix that was
not publicly disclosed until it was released. Changing the other
files was not needed for the minimal fix.
However, it's still a reasonable idea to forbid symlinks for these
files:
- As noted, they can still be used to read out-of-repo files (which is
fairly restricted, but in some circumstances you can probe file
content by speculatively creating files and seeing if they get
ignored)
- They don't currently behave well in all cases. We sometimes read
these files from the index, where we _don't_ follow symlinks (we'd
just treat the symlink target as the .gitignore or .gitattributes
content, which is actively wrong).
This patch forbids symlinked versions of these files from entering the
index. We already have helpers for obscured forms of the names from
e7cb0b4455 (is_ntfs_dotgit: match other .git files, 2018-05-11) and
0fc333ba20 (is_hfs_dotgit: match other .git files, 2018-05-02), which
were done as part of the series touching .gitmodules.
No tests yet, as we'll add them in a subsequent patch once we have fsck
support, too.
Signed-off-by: Jeff King <peff@peff.net>
---
read-cache.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index ecf6f68994..63aec6c35d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -947,7 +947,9 @@ static int verify_dotfile(const char *rest, unsigned mode)
return 0;
if (S_ISLNK(mode)) {
rest += 3;
- if (skip_iprefix(rest, "modules", &rest) &&
+ if ((skip_iprefix(rest, "modules", &rest) ||
+ skip_iprefix(rest, "ignore", &rest) ||
+ skip_iprefix(rest, "attributes", &rest)) &&
(*rest == '\0' || is_dir_sep(*rest)))
return 0;
}
@@ -980,7 +982,9 @@ int verify_path(const char *path, unsigned mode)
if (is_hfs_dotgit(path))
return 0;
if (S_ISLNK(mode)) {
- if (is_hfs_dotgitmodules(path))
+ if (is_hfs_dotgitmodules(path) ||
+ is_hfs_dotgitignore(path) ||
+ is_hfs_dotgitattributes(path))
return 0;
}
}
@@ -992,7 +996,9 @@ int verify_path(const char *path, unsigned mode)
if (is_ntfs_dotgit(path))
return 0;
if (S_ISLNK(mode)) {
- if (is_ntfs_dotgitmodules(path))
+ if (is_ntfs_dotgitmodules(path) ||
+ is_ntfs_dotgitignore(path) ||
+ is_ntfs_dotgitattributes(path))
return 0;
}
}
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-05 12:16 ` [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore Jeff King
@ 2020-10-27 3:35 ` Jonathan Nieder
2020-10-27 7:58 ` Jeff King
0 siblings, 1 reply; 55+ messages in thread
From: Jonathan Nieder @ 2020-10-27 3:35 UTC (permalink / raw)
To: Jeff King; +Cc: git
Hi,
Jeff King wrote:
> However, it's still a reasonable idea to forbid symlinks for these
> files:
>
> - As noted, they can still be used to read out-of-repo files (which is
> fairly restricted, but in some circumstances you can probe file
> content by speculatively creating files and seeing if they get
> ignored)
>
> - They don't currently behave well in all cases. We sometimes read
> these files from the index, where we _don't_ follow symlinks (we'd
> just treat the symlink target as the .gitignore or .gitattributes
> content, which is actively wrong).
>
> This patch forbids symlinked versions of these files from entering the
> index. We already have helpers for obscured forms of the names from
> e7cb0b4455 (is_ntfs_dotgit: match other .git files, 2018-05-11) and
> 0fc333ba20 (is_hfs_dotgit: match other .git files, 2018-05-02), which
> were done as part of the series touching .gitmodules.
Thanks again for this. Since this patch has been in "next", we've
gotten a little experience of it at Google.
We've been running with the fsck check for a while (more than a year),
but not the verify_dotfile check. The verify_dotfile check didn't
trigger for anyone with .gitattributes, but it hit several people for
.gitignore. Some examples that users have mentioned:
Before https://android-review.googlesource.com/c/platform/tools/test/connectivity/+/1462771/
Android used a .gitignore symlink for two directories that had similar
gitignore requirements. Diagnosing the error was confusing for them,
especially because the "repo" wrapper tool produced messages like
error.GitError: Cannot initialize work tree for platform/tools/test/connectivity
Eventually someone manually ran
$ git add --a
error: invalid path 'acts_tests/.gitignore'
error: unable to add 'acts_tests/.gitignore' to index
fatal: adding files failed
which helped them realize it was a git issue and helped me point them
to the need to replace the symlink with a plain file.
As another example, a user working with the
https://github.com/bakerstu/openmrn.git repository noticed "git
checkout" commands failing. In this user's case, the checkout failed
part-way through, producing confusing behavior ("git status" showing
entries missing from the index). When I tried to reproduce this, I
wasn't able to clone the repository at all because it failed fsck;
after disabling transfer.fsckObjects, I still wasn't able to check out
HEAD.
Observations:
- since some widely used repositories have .gitignore symlinks, I
think we can't forbid it in fsck, alas
- it would be useful to be able to check whether these symlinks would
not escape the worktree, for a more targeted check. It might be
nice to even respect these settings when they would not escape the
worktree, but not necessarily
- we could use a clearer error message than "invalid path". There's
some room for improvement in "git checkout"'s error handling, too
--- I think my ideal would be if the operation would fail entirely,
with an advice message describing a checkout command that would
succeed (But how do I checkout another commit while excluding some
files? Should it suggest a sparse checkout?).
That's all I have time for today --- will revisit again tomorrow.
Thoughts?
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-27 3:35 ` Jonathan Nieder
@ 2020-10-27 7:58 ` Jeff King
2020-10-27 22:00 ` Junio C Hamano
2020-10-27 23:43 ` Jonathan Nieder
0 siblings, 2 replies; 55+ messages in thread
From: Jeff King @ 2020-10-27 7:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
On Mon, Oct 26, 2020 at 08:35:18PM -0700, Jonathan Nieder wrote:
> As another example, a user working with the
> https://github.com/bakerstu/openmrn.git repository noticed "git
> checkout" commands failing. In this user's case, the checkout failed
> part-way through, producing confusing behavior ("git status" showing
> entries missing from the index). When I tried to reproduce this, I
> wasn't able to clone the repository at all because it failed fsck;
> after disabling transfer.fsckObjects, I still wasn't able to check out
> HEAD.
I wouldn't be surprised if there are code paths which die() early
instead of checking out as much as they can. But I think fixing that is
somewhat orthogonal (here we're just adding new reasons that checking
out may fail).
> Observations:
>
> - since some widely used repositories have .gitignore symlinks, I
> think we can't forbid it in fsck, alas
I am a little puzzled here. You said you had the fsck checks for the
last year, so why did they just come up now? I guess nobody sets
transfer.fsckObjects, and because you were testing only with clients,
your server implementation didn't reject pushes?
I agree it's annoying for them if they fail fsck, but it's not entirely
a show-stopper. There are config options for fine-tuning what you're
willing to enforce or ignore. But they of course are also annoying to
use, because every receiver of a transfer needs to set them (on GitHub,
for example, you have to email Support).
So I won't be too devastated to remove the symlink checks, or possibly
downgrade them to purely warnings (or "info"; the naming in fsck.c is
confusing, because the transfer operations take even warnings as fatal.
I suspect we could do with some cleanup there).
> - it would be useful to be able to check whether these symlinks would
> not escape the worktree, for a more targeted check. It might be
> nice to even respect these settings when they would not escape the
> worktree, but not necessarily
I actually wrote a patch several years ago for checking symlinks (not
just these ones, but _any_ symlinks in the repo, but of course it would
be easy to limit it more). It's included at the end of this mail. It's
been part of my daily build for many years, so I'm confident it doesn't
crash or have other bad behavior. But it's possible the logic for what
it catches is faulty.
> - we could use a clearer error message than "invalid path".
That part is tricky. The "invalid path" error comes from the caller of
verify_path(), and we have no way to pass back an intelligent error
there. We can call error() ourselves, of course. That adds an extra line
of output, but it's rare enough for verify_path() to fail that it's
likely OK. However, I would worry that some callers might be surprised
by it producing output at all.
An alternative is letting the caller pass in a strbuf that we fill out
with an extra error string.
> There's some room for improvement in "git checkout"'s error handling,
> too --- I think my ideal would be if the operation would fail
> entirely, with an advice message describing a checkout command that
> would succeed (But how do I checkout another commit while excluding
> some files? Should it suggest a sparse checkout?).
I suspect it's too late for "fail entirely". We may have already written
to the filesystem, and rolling back is difficult and error-prone. In
general I'd expect to checkout what we can, produce errors for the rest,
and let the user work from there with "git status".
But I may be wrong. The problem is loading the value into the index, not
writing it to the filesystem. So perhaps the relevant code paths load
the index fully before writing out anything to the filesystem, and it's
easy to rollback. But I imagine they are using unpack-trees' flag to
update the filesystem, and I assume that checks out as it loads entries
(but I didn't confirm).
-Peff
Here's the patch. The tests need the checkout-index fix from:
https://lore.kernel.org/git/20201027073000.GA3651896@coredump.intra.peff.net/
but it should otherwise be stand-alone. I don't recall why I never sent
it. One obvious downside is that it's difficult to have fsck checks for
it, since the full path of an entry is not a property of a single tree
object.
-- >8 --
Date: Wed, 9 Nov 2016 23:24:09 -0500
Subject: [PATCH] optionally block out-of-repo symlinks
---
apply.c | 2 +-
cache.h | 3 +
config.c | 5 ++
entry.c | 2 +-
environment.c | 1 +
merge-recursive.c | 2 +-
path.c | 73 ++++++++++++++++++
t/t2031-checkout-symlink-external.sh | 107 +++++++++++++++++++++++++++
8 files changed, 192 insertions(+), 3 deletions(-)
create mode 100755 t/t2031-checkout-symlink-external.sh
diff --git a/apply.c b/apply.c
index 76dba93c97..2ac940dc05 100644
--- a/apply.c
+++ b/apply.c
@@ -4360,7 +4360,7 @@ static int try_create_file(struct apply_state *state, const char *path,
/* Although buf:size is counted string, it also is NUL
* terminated.
*/
- return !!symlink(buf, path);
+ return !!safe_symlink(buf, path);
fd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);
if (fd < 0)
diff --git a/cache.h b/cache.h
index c0072d43b1..9b56e2327a 100644
--- a/cache.h
+++ b/cache.h
@@ -959,6 +959,7 @@ extern int precomposed_unicode;
extern int protect_hfs;
extern int protect_ntfs;
extern const char *core_fsmonitor;
+extern int allow_external_symlinks;
extern int core_apply_sparse_checkout;
extern int core_sparse_checkout_cone;
@@ -1979,4 +1980,6 @@ int print_sha1_ellipsis(void);
/* Return 1 if the file is empty or does not exists, 0 otherwise. */
int is_empty_or_missing_file(const char *filename);
+int safe_symlink(const char *target, const char *linkpath);
+
#endif /* CACHE_H */
diff --git a/config.c b/config.c
index 2bdff4457b..6699881c6e 100644
--- a/config.c
+++ b/config.c
@@ -1404,6 +1404,11 @@ static int git_default_core_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "core.allowexternalsymlinks")) {
+ allow_external_symlinks = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return platform_core_config(var, value, cb);
}
diff --git a/entry.c b/entry.c
index a0532f1f00..f2d3456df3 100644
--- a/entry.c
+++ b/entry.c
@@ -291,7 +291,7 @@ static int write_entry(struct cache_entry *ce,
if (!has_symlinks || to_tempfile)
goto write_file_entry;
- ret = symlink(new_blob, path);
+ ret = safe_symlink(new_blob, path);
free(new_blob);
if (ret)
return error_errno("unable to create symlink %s", path);
diff --git a/environment.c b/environment.c
index bb518c61cd..7c233e0e0e 100644
--- a/environment.c
+++ b/environment.c
@@ -73,6 +73,7 @@ int merge_log_config = -1;
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
unsigned long pack_size_limit_cfg;
enum log_refs_config log_all_ref_updates = LOG_REFS_UNSET;
+int allow_external_symlinks = 1;
#ifndef PROTECT_HFS_DEFAULT
#define PROTECT_HFS_DEFAULT 0
diff --git a/merge-recursive.c b/merge-recursive.c
index d0214335a7..61208a8b43 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -986,7 +986,7 @@ static int update_file_flags(struct merge_options *opt,
char *lnk = xmemdupz(buf, size);
safe_create_leading_directories_const(path);
unlink(path);
- if (symlink(lnk, path))
+ if (safe_symlink(lnk, path))
ret = err(opt, _("failed to symlink '%s': %s"),
path, strerror(errno));
free(lnk);
diff --git a/path.c b/path.c
index 7b385e5eb2..251dd70ff5 100644
--- a/path.c
+++ b/path.c
@@ -1498,6 +1498,79 @@ int looks_like_command_line_option(const char *str)
return str && str[0] == '-';
}
+static int symlink_leaves_repo(const char *target, const char *linkpath)
+{
+ /*
+ * Absolute paths are always considered to leave the repository (even
+ * if they happen to point to the working tree path).
+ */
+ if (is_absolute_path(target))
+ return 1;
+
+ /*
+ * Allow relative paths that start with a sequence of "../",
+ * as long as they do not break out of the symlink's root.
+ * This loop will detect break-out cases and return; otherwise, at the
+ * end of the loop "target" will point to the first non-".." component.
+ *
+ * We count the depth of linkpath by eating up directory components left
+ * to right. Technically the symlink would resolve right-to-left, but
+ * we don't care about the actual values, only the number.
+ */
+ while (target[0] == '.') {
+ if (!target[1]) {
+ /* trailing "." -- ignore */
+ target++;
+ } else if (is_dir_sep(target[1])) {
+ /* "./" -- ignore */
+ target += 2;
+ } else if (target[1] == '.' &&
+ (!target[2] || is_dir_sep(target[2]))) {
+ /* ".." or "../" -- drop one from linkpath depth */
+ while (!is_dir_sep(*linkpath)) {
+ /* end-of-string; target exceeded our depth */
+ if (!*linkpath)
+ return 1;
+ linkpath++;
+ }
+ /* skip final "/" */
+ linkpath++;
+
+ /* skip past ".." */
+ target += 2;
+ /* and "/" if present */
+ if (is_dir_sep(*target))
+ target++;
+ }
+ }
+
+ /*
+ * Now we have a path in "target" that only go down into the tree.
+ * Disallow any interior "../", like "foo/../bar". These might be
+ * OK, but we cannot know unless we know whether "foo" is itself a
+ * symlink. So err on the side of caution.
+ */
+ while (*target) {
+ const char *v;
+ if (skip_prefix(target, "..", &v) && (!*v || is_dir_sep(*v)))
+ return 1;
+ target++;
+ }
+
+ return 0;
+}
+
+int safe_symlink(const char *target, const char *linkpath)
+{
+ if (!allow_external_symlinks &&
+ symlink_leaves_repo(target, linkpath)) {
+ errno = EPERM;
+ return -1;
+ }
+
+ return symlink(target, linkpath);
+}
+
char *xdg_config_home(const char *filename)
{
const char *home, *config_home;
diff --git a/t/t2031-checkout-symlink-external.sh b/t/t2031-checkout-symlink-external.sh
new file mode 100755
index 0000000000..c799f8158e
--- /dev/null
+++ b/t/t2031-checkout-symlink-external.sh
@@ -0,0 +1,107 @@
+#!/bin/sh
+
+test_description='detection and prevention of out-of-tree symlinks'
+. ./test-lib.sh
+
+if ! test_have_prereq SYMLINKS
+then
+ skip_all='skipping external symlink tests (missing SYMLINKS)'
+ test_done
+fi
+
+create_symlink() {
+ symlink=$1
+ target=$2
+ test_expect_success "create symlink ($symlink)" '
+ sha1=$(printf "%s" "$target" | git hash-object -w --stdin) &&
+ git update-index --add --cacheinfo "120000,$sha1,$symlink"
+ '
+}
+
+check_symlink () {
+ symlink=$1
+ config=$2
+ outcome=$3
+ expect=$4
+
+ if test "$outcome" = "allow"
+ then
+ fail=
+ : ${expect:=test_cmp ../target}
+ else
+ fail=test_must_fail
+ : ${expect:=! cat}
+ fi
+
+ test_expect_success " check symlink ($symlink, $config -> $outcome)" "
+ rm -f $symlink &&
+ $fail git -c core.allowExternalSymlinks=$config \\
+ checkout-index -- $symlink &&
+ $expect $symlink
+ "
+}
+
+# we want to try breaking out of the repository,
+# so let's work inside a sub-repository, and break
+# out to the top-level trash directory
+test_expect_success 'set up repository' '
+ echo content >target &&
+ git init subrepo &&
+ cd subrepo &&
+ test_commit base &&
+ echo content >in-repo-target
+'
+
+create_symlink in-repo in-repo-target
+check_symlink in-repo false allow
+
+create_symlink subdir/in-repo ../in-repo-target
+check_symlink subdir/in-repo false allow
+
+create_symlink absolute "$TRASH_DIRECTORY/target"
+check_symlink absolute true allow
+check_symlink absolute false forbid
+
+create_symlink relative "../target"
+check_symlink relative true allow
+check_symlink relative false forbid
+
+create_symlink curdir .
+check_symlink curdir false allow test_path_is_dir
+create_symlink sneaky curdir/../target
+check_symlink sneaky true allow
+check_symlink sneaky false forbid
+
+test_expect_success 'applying a patch checks symlink config' '
+ git diff-index -p --cached HEAD -- relative >patch &&
+ rm -f relative &&
+ git -c core.allowExternalSymlinks=true apply <patch &&
+ test_cmp ../target relative &&
+ rm -f relative &&
+ test_must_fail git -c core.allowExternalSymlinks=false apply <patch
+'
+
+test_expect_success 'merge-recursive checks symlinks config' '
+ git reset --hard &&
+
+ # create rename situation which requires processing
+ # outside of unpack_trees()
+ ln -s ../foo one &&
+ git add one &&
+ git commit -m base &&
+
+ ln -sf ../target one &&
+ git commit -am modify &&
+
+ git checkout -b side HEAD^ &&
+ git mv one two &&
+ git commit -am rename &&
+
+ git -c core.allowExternalSymlinks=true merge master &&
+ test_cmp ../target two &&
+
+ git reset --hard HEAD^ &&
+ test_must_fail git -c core.allowExternalSymlinks=false merge master
+'
+
+test_done
--
2.29.1.634.g9e41dc1bf2
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-27 7:58 ` Jeff King
@ 2020-10-27 22:00 ` Junio C Hamano
2020-10-28 9:41 ` Jeff King
2020-10-27 23:43 ` Jonathan Nieder
1 sibling, 1 reply; 55+ messages in thread
From: Junio C Hamano @ 2020-10-27 22:00 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git
Jeff King <peff@peff.net> writes:
> diff --git a/environment.c b/environment.c
> index bb518c61cd..7c233e0e0e 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -73,6 +73,7 @@ int merge_log_config = -1;
> int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
> unsigned long pack_size_limit_cfg;
> enum log_refs_config log_all_ref_updates = LOG_REFS_UNSET;
> +int allow_external_symlinks = 1;
OK, so by default it is not blocked...
> +static int symlink_leaves_repo(const char *target, const char *linkpath)
> +{
> + /*
> + * Absolute paths are always considered to leave the repository (even
> + * if they happen to point to the working tree path).
> + */
> + if (is_absolute_path(target))
> + return 1;
Very sensible.
> + /*
> + * Allow relative paths that start with a sequence of "../",
> + * as long as they do not break out of the symlink's root.
> + * This loop will detect break-out cases and return; otherwise, at the
> + * end of the loop "target" will point to the first non-".." component.
> + *
> + * We count the depth of linkpath by eating up directory components left
> + * to right. Technically the symlink would resolve right-to-left, but
> + * we don't care about the actual values, only the number.
> + */
> + while (target[0] == '.') {
> + if (!target[1]) {
> + /* trailing "." -- ignore */
> + target++;
> + } else if (is_dir_sep(target[1])) {
> + /* "./" -- ignore */
> + target += 2;
> + } else if (target[1] == '.' &&
> + (!target[2] || is_dir_sep(target[2]))) {
> + /* ".." or "../" -- drop one from linkpath depth */
> + while (!is_dir_sep(*linkpath)) {
> + /* end-of-string; target exceeded our depth */
> + if (!*linkpath)
> + return 1;
> + linkpath++;
> + }
> + /* skip final "/" */
> + linkpath++;
> +
> + /* skip past ".." */
> + target += 2;
> + /* and "/" if present */
> + if (is_dir_sep(*target))
> + target++;
> + }
> + }
> +
> + /*
> + * Now we have a path in "target" that only go down into the tree.
> + * Disallow any interior "../", like "foo/../bar". These might be
> + * OK, but we cannot know unless we know whether "foo" is itself a
> + * symlink. So err on the side of caution.
> + */
> + while (*target) {
> + const char *v;
> + if (skip_prefix(target, "..", &v) && (!*v || is_dir_sep(*v)))
> + return 1;
> + target++;
> + }
> +
> + return 0;
> +}
> +
> +int safe_symlink(const char *target, const char *linkpath)
> +{
> + if (!allow_external_symlinks &&
> + symlink_leaves_repo(target, linkpath)) {
> + errno = EPERM;
> + return -1;
> + }
> +
> + return symlink(target, linkpath);
> +}
OK. This is only about blocking creation of new symbolic links that
goes outside the working tree. It obviously is a good thing to do.
We have some "symlink safety" in various parts of the system [*1*],
and I wonder if we can somehow consolidate the support to a more
central place.
Thanks.
[Footnote]
*1* For example, apply tries to be careful not to take the "path"
recorded in the incoming patch blindly, and instead checks if
any path component in it is a symbolic link before touching.
Similarly, callers of has_symlink_leading_path() all try to be
careful when the "path" they want to use to access a filesystem
entity has a symbolic link in the middle on the filesystem.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-27 22:00 ` Junio C Hamano
@ 2020-10-28 9:41 ` Jeff King
0 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-28 9:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
On Tue, Oct 27, 2020 at 03:00:36PM -0700, Junio C Hamano wrote:
> > + /*
> > + * Now we have a path in "target" that only go down into the tree.
> > + * Disallow any interior "../", like "foo/../bar". These might be
> > + * OK, but we cannot know unless we know whether "foo" is itself a
> > + * symlink. So err on the side of caution.
> > + */
> > + while (*target) {
> > + const char *v;
> > + if (skip_prefix(target, "..", &v) && (!*v || is_dir_sep(*v)))
> > + return 1;
> > + target++;
> > + }
Just reading over the patch again, I suspect this is overly eager to
find ".." that is not bordered by a directory separator on the left-hand
side (e.g., I think it will match "foo../").
> > +int safe_symlink(const char *target, const char *linkpath)
> > +{
> > + if (!allow_external_symlinks &&
> > + symlink_leaves_repo(target, linkpath)) {
> > + errno = EPERM;
> > + return -1;
> > + }
> > +
> > + return symlink(target, linkpath);
> > +}
>
> OK. This is only about blocking creation of new symbolic links that
> goes outside the working tree. It obviously is a good thing to do.
>
> We have some "symlink safety" in various parts of the system [*1*],
> and I wonder if we can somehow consolidate the support to a more
> central place.
Note that it is overly conservative, as described in the comment quoted
at the top of this email. It's possible that other code might be able to
be more accurate because it can see "/foo/" in the middle of a symlink
target and actually _look_ at "foo". Does it exist, is it a symlink
itself, etc.
Whereas here we're taking a purely textual look at the target. We have
to, I think, because we don't know if or when that "foo" will get
updated. And maybe that same restriction applies to other parts of the
system, or maybe not.
At any rate, I don't really have plans to push this particular topic
forward, at least not in the near term. I was mostly sharing it in case
anybody found it useful. If somebody wants to run with it, please be my
guest.
-Peff
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-27 7:58 ` Jeff King
2020-10-27 22:00 ` Junio C Hamano
@ 2020-10-27 23:43 ` Jonathan Nieder
2020-10-28 19:18 ` Junio C Hamano
1 sibling, 1 reply; 55+ messages in thread
From: Jonathan Nieder @ 2020-10-27 23:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King wrote:
> On Mon, Oct 26, 2020 at 08:35:18PM -0700, Jonathan Nieder wrote:
>> Observations:
>>
>> - since some widely used repositories have .gitignore symlinks, I
>> think we can't forbid it in fsck, alas
>
> I am a little puzzled here. You said you had the fsck checks for the
> last year, so why did they just come up now? I guess nobody sets
> transfer.fsckObjects, and because you were testing only with clients,
> your server implementation didn't reject pushes?
>
> I agree it's annoying for them if they fail fsck, but it's not entirely
> a show-stopper. There are config options for fine-tuning what you're
> willing to enforce or ignore. But they of course are also annoying to
> use, because every receiver of a transfer needs to set them (on GitHub,
> for example, you have to email Support).
Yes. And to reiterate the point a little: the reason nobody sets
transfer.fsckObjects is that we haven't made it easy to distinguish
between "hard error, should never be overridden" checks (like
BAD_PARENT_SHA1), "new tools shouldn't write these but they exist in
important repos like perl.git and anything consuming Git repositories
needs to cope with them" (like MISSING_SPACE_BEFORE_DATE from some
commits' concatenated authors), and so on.
> So I won't be too devastated to remove the symlink checks, or possibly
> downgrade them to purely warnings (or "info"; the naming in fsck.c is
> confusing, because the transfer operations take even warnings as fatal.
> I suspect we could do with some cleanup there).
Downgrading the .gitignore check to warning sounds okay. .gitmodules
would still want to be an error, of course.
>> - it would be useful to be able to check whether these symlinks would
>> not escape the worktree, for a more targeted check. It might be
>> nice to even respect these settings when they would not escape the
>> worktree, but not necessarily
>
> I actually wrote a patch several years ago for checking symlinks (not
> just these ones, but _any_ symlinks in the repo, but of course it would
> be easy to limit it more). It's included at the end of this mail. It's
> been part of my daily build for many years, so I'm confident it doesn't
> crash or have other bad behavior. But it's possible the logic for what
> it catches is faulty.
[...]
> Here's the patch.
Nice! I'll try to find time to experiment with this.
[...]
>> - we could use a clearer error message than "invalid path".
>
> That part is tricky. The "invalid path" error comes from the caller of
> verify_path(), and we have no way to pass back an intelligent error
> there. We can call error() ourselves, of course. That adds an extra line
> of output, but it's rare enough for verify_path() to fail that it's
> likely OK. However, I would worry that some callers might be surprised
> by it producing output at all.
>
> An alternative is letting the caller pass in a strbuf that we fill out
> with an extra error string.
I think passing in a struct to govern error handling sounds nice.
Alternatively, this might suggest that verify_path is not the right
place for the user-facing check: it's useful because it's exhaustive,
but it may be that we can also catch the same issue earlier and
produce a nicer diagnostic.
>> There's some room for improvement in "git checkout"'s error handling,
>> too --- I think my ideal would be if the operation would fail
>> entirely, with an advice message describing a checkout command that
>> would succeed (But how do I checkout another commit while excluding
>> some files? Should it suggest a sparse checkout?).
>
> I suspect it's too late for "fail entirely". We may have already written
> to the filesystem, and rolling back is difficult and error-prone. In
> general I'd expect to checkout what we can, produce errors for the rest,
> and let the user work from there with "git status".
>
> But I may be wrong. The problem is loading the value into the index, not
> writing it to the filesystem. So perhaps the relevant code paths load
> the index fully before writing out anything to the filesystem, and it's
> easy to rollback. But I imagine they are using unpack-trees' flag to
> update the filesystem, and I assume that checks out as it loads entries
> (but I didn't confirm).
Right, this would require taking two passes. I think we do already
perform two passes (first deletions, then additions); I'll have to
look a little more closely to see whether this is straightforward to
do.
I do still like the idea of not respecting .gitignore and
.gitattributes symlinks, by the way. What the experiences upthread
tell me is just that users need better facilities for repairing
existing repositories.
Thanks,
Jonathan
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore
2020-10-27 23:43 ` Jonathan Nieder
@ 2020-10-28 19:18 ` Junio C Hamano
0 siblings, 0 replies; 55+ messages in thread
From: Junio C Hamano @ 2020-10-28 19:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, git
Jonathan Nieder <jrnieder@gmail.com> writes:
> Yes. And to reiterate the point a little: the reason nobody sets
> transfer.fsckObjects is that we haven't made it easy to distinguish
> between "hard error, should never be overridden" checks (like
> BAD_PARENT_SHA1), "new tools shouldn't write these but they exist in
> important repos like perl.git and anything consuming Git repositories
> needs to cope with them" (like MISSING_SPACE_BEFORE_DATE from some
> commits' concatenated authors), and so on.
Hmph, don't we "distinguish" them by setting appropriate default
levels, though? Perhaps some classes of errors are set too strict?
>> So I won't be too devastated to remove the symlink checks, or possibly
>> downgrade them to purely warnings (or "info"; the naming in fsck.c is
>> confusing, because the transfer operations take even warnings as fatal.
>> I suspect we could do with some cleanup there).
>
> Downgrading the .gitignore check to warning sounds okay. .gitmodules
> would still want to be an error, of course.
.gitattributes (and any other .git<thing> we may have in the
future), too.
Thanks.
^ permalink raw reply [flat|nested] 55+ messages in thread
* [PATCH v2 8/8] fsck: complain when .gitattributes or .gitignore is a symlink
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (6 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore Jeff King
@ 2020-10-05 12:16 ` Jeff King
2020-10-06 20:41 ` [PATCH v2 0/8] forbidding symlinked .gitattributes and .gitignore Junio C Hamano
2020-10-20 23:19 ` Philip Oakley
9 siblings, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-05 12:16 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder
The previous commit made it impossible to have a symlinked
.gitattributes or .gitignore file via verify_path(). Let's add the same
check to fsck, which matches how we handle .gitmodules symlinks, via
b7b1fca175 (fsck: complain when .gitmodules is a symlink, 2018-05-04).
Note that we won't add these to the existing gitmodules block. 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 (and this covers the verify_path() change from the previous
commit, as well).
Signed-off-by: Jeff King <peff@peff.net>
---
fsck.c | 15 +++++++++++++++
t/t7450-bad-dotgitx-files.sh | 8 ++++++++
2 files changed, 23 insertions(+)
diff --git a/fsck.c b/fsck.c
index 024810139b..fcd3f268b1 100644
--- a/fsck.c
+++ b/fsck.c
@@ -67,6 +67,8 @@ static struct oidset gitmodules_done = OIDSET_INIT;
FUNC(GITMODULES_URL, ERROR) \
FUNC(GITMODULES_PATH, ERROR) \
FUNC(GITMODULES_UPDATE, ERROR) \
+ FUNC(GITIGNORE_SYMLINK, ERROR) \
+ FUNC(GITATTRIBUTES_SYMLINK, ERROR) \
/* warnings */ \
FUNC(BAD_FILEMODE, WARN) \
FUNC(EMPTY_NAME, WARN) \
@@ -688,6 +690,19 @@ static int fsck_tree(const struct object_id *tree_oid,
".gitmodules is a symbolic link");
}
+ if (S_ISLNK(mode)) {
+ if (is_hfs_dotgitignore(name) ||
+ is_ntfs_dotgitignore(name))
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_GITIGNORE_SYMLINK,
+ ".gitignore is a symlink");
+ if (is_hfs_dotgitattributes(name) ||
+ is_ntfs_dotgitattributes(name))
+ retval += report(options, tree_oid, OBJ_TREE,
+ FSCK_MSG_GITATTRIBUTES_SYMLINK,
+ ".gitattributes is a symlink");
+ }
+
if ((backslash = strchr(name, '\\'))) {
while (backslash) {
backslash++;
diff --git a/t/t7450-bad-dotgitx-files.sh b/t/t7450-bad-dotgitx-files.sh
index 0cd0f71c39..326b34e167 100755
--- a/t/t7450-bad-dotgitx-files.sh
+++ b/t/t7450-bad-dotgitx-files.sh
@@ -193,6 +193,14 @@ check_forbidden_symlink gitmodules vanilla .gitmodules
check_forbidden_symlink gitmodules ntfs ".gitmodules ."
check_forbidden_symlink gitmodules hfs ".${u200c}gitmodules"
+check_forbidden_symlink gitattributes vanilla .gitattributes
+check_forbidden_symlink gitattributes ntfs ".gitattributes ."
+check_forbidden_symlink gitattributes hfs ".${u200c}gitattributes"
+
+check_forbidden_symlink gitignore vanilla .gitignore
+check_forbidden_symlink gitignore ntfs ".gitignore ."
+check_forbidden_symlink gitignore hfs ".${u200c}gitignore"
+
test_expect_success 'fsck detects non-blob .gitmodules' '
git init non-blob &&
(
--
2.28.0.1295.gf70bcb366f
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH v2 0/8] forbidding symlinked .gitattributes and .gitignore
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (7 preceding siblings ...)
2020-10-05 12:16 ` [PATCH v2 8/8] fsck: complain when .gitattributes or .gitignore is a symlink Jeff King
@ 2020-10-06 20:41 ` Junio C Hamano
2020-10-20 23:19 ` Philip Oakley
9 siblings, 0 replies; 55+ messages in thread
From: Junio C Hamano @ 2020-10-06 20:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jonathan Nieder
Jeff King <peff@peff.net> writes:
> On Mon, Oct 05, 2020 at 03:17:51AM -0400, Jeff King wrote:
>
>> About 2 years ago as part of a security release we made it illegal to
>> have a symlinked .gitmodules file (refusing it both in the index and via
>> fsck). At the time we discussed (on the security list) outlawing
>> symlinks for other .git files in the same way, but we decided not to do
>> so as part of the security release, as it wasn't strictly necessary.
>>
>> We publicly revisited the topic in:
>>
>> https://lore.kernel.org/git/20190114230902.GG162110@google.com/
>>
>> but there were a few fixes needed, and it got forgotten. So here it is
>> again, with those fixes:
>> [...]
>
> And here's a v2 incorporating feedback from Jonathan. There are no
> substantial changes in the code. Most of the fixes are cosmetic, but the
> tests are beefed up a bit, as well:
>
> - we now test that ntfs and hfs names are matched via fsck and
> verify_path() for all file types. The bulk of this is in a new patch
> 5, and the final patches are adjusted to use the new helper.
>
> - we confirm that read-tree doesn't write the forbidden entry into the
> index (in addition to seeing that it complains)
>
> - the test script name is now "bad-dotgitx" instead of the vague
> "bad-meta-files"
>
> - whitespace, typo-fixes, clarity, etc; the range diff is below
Thanks for a pleasant read. Will queue.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH v2 0/8] forbidding symlinked .gitattributes and .gitignore
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
` (8 preceding siblings ...)
2020-10-06 20:41 ` [PATCH v2 0/8] forbidding symlinked .gitattributes and .gitignore Junio C Hamano
@ 2020-10-20 23:19 ` Philip Oakley
2020-10-23 8:17 ` [PATCH] documentation symlink restrictions for .git* files Jeff King
9 siblings, 1 reply; 55+ messages in thread
From: Philip Oakley @ 2020-10-20 23:19 UTC (permalink / raw)
To: Jeff King, git; +Cc: Jonathan Nieder
A rather late comment,
On 05/10/2020 13:16, Jeff King wrote:
> On Mon, Oct 05, 2020 at 03:17:51AM -0400, Jeff King wrote:
>
>> About 2 years ago as part of a security release we made it illegal to
>> have a symlinked .gitmodules file (refusing it both in the index and via
>> fsck). At the time we discussed (on the security list) outlawing
>> symlinks for other .git files in the same way, but we decided not to do
>> so as part of the security release, as it wasn't strictly necessary.
Is this something that should be recorded in the documentation, either as a
simple (sensible) limitation, or explicitly as a security related safety
measure?
I didn't see any changes to the .txt docs in the change list below.
Philip
>>
>> We publicly revisited the topic in:
>>
>> https://lore.kernel.org/git/20190114230902.GG162110@google.com/
>>
>> but there were a few fixes needed, and it got forgotten. So here it is
>> again, with those fixes:
>> [...]
> And here's a v2 incorporating feedback from Jonathan. There are no
> substantial changes in the code. Most of the fixes are cosmetic, but the
> tests are beefed up a bit, as well:
>
> - we now test that ntfs and hfs names are matched via fsck and
> verify_path() for all file types. The bulk of this is in a new patch
> 5, and the final patches are adjusted to use the new helper.
>
> - we confirm that read-tree doesn't write the forbidden entry into the
> index (in addition to seeing that it complains)
>
> - the test script name is now "bad-dotgitx" instead of the vague
> "bad-meta-files"
>
> - whitespace, typo-fixes, clarity, etc; the range diff is below
>
> [1/8]: fsck_tree(): fix shadowed variable
> [2/8]: fsck_tree(): wrap some long lines
> [3/8]: t7415: rename to expand scope
> [4/8]: t7450: test verify_path() handling of gitmodules
> [5/8]: t7450: test .gitmodules symlink matching against obscured names
> [6/8]: t0060: test obscured .gitattributes and .gitignore matching
> [7/8]: verify_path(): disallow symlinks in .gitattributes and .gitignore
> [8/8]: fsck: complain when .gitattributes or .gitignore is a symlink
>
> fsck.c | 79 +++++++++++----
> read-cache.c | 12 ++-
> t/helper/test-path-utils.c | 41 +++++---
> t/t0060-path-utils.sh | 20 ++++
> ...le-names.sh => t7450-bad-dotgitx-files.sh} | 99 +++++++++++++------
> 5 files changed, 187 insertions(+), 64 deletions(-)
> rename t/{t7415-submodule-names.sh => t7450-bad-dotgitx-files.sh} (73%)
>
> 1: d4c4b98188 ! 1: 78689a44ba fsck_tree(): fix shadowed variable
> @@ Commit message
>
> Let's rename both variables in the function to avoid confusion. This
> makes the diff a little noisy (e.g., all of the report() calls outside
> - the loop wee already correct but need touched), but makes sure we catch
> - all cases and will avoid similar confusion in the future.
> + the loop were already correct but need to be touched), but makes sure we
> + catch all cases and will avoid similar confusion in the future.
> +
> + Note that our test change removes the comment about translation. It was
> + arguably confusing since 674ba34038 (fsck: mark strings for translation,
> + 2018-11-10); we wouldn't translate gitmodulesSymlink, but it did get
> + removed by GETTEXT_POISON because that feature eats embedded
> + %s characters. But certainly after this patch, when we look for the
> + "tree %s: %s" format, we could get foiled by translation.
>
> Signed-off-by: Jeff King <peff@peff.net>
>
> @@ t/t7415-submodule-names.sh: test_expect_success 'fsck detects symlinked .gitmodu
> + tree=$(git mktree <bad-tree) &&
>
> # Check not only that we fail, but that it is due to the
> - # symlink detector; this grep string comes from the config
> - # variable name and will not be translated.
> +- # symlink detector; this grep string comes from the config
> +- # variable name and will not be translated.
> ++ # symlink detector
> test_must_fail git fsck 2>output &&
> - test_i18ngrep gitmodulesSymlink output
> + test_i18ngrep "tree $tree: gitmodulesSymlink" output
> 2: 29d0d3af44 = 2: b1f7ec465c fsck_tree(): wrap some long lines
> 3: 8679f0b2f2 ! 3: d26ef683fd t7415: rename to expand scope
> @@ Commit message
>
> Signed-off-by: Jeff King <peff@peff.net>
>
> - ## t/t7415-submodule-names.sh => t/t7450-bad-meta-files.sh ##
> + ## t/t7415-submodule-names.sh => t/t7450-bad-dotgitx-files.sh ##
> @@
> #!/bin/sh
>
> 4: 84e58f7f46 ! 4: 493a4c79a3 t7450: test verify_path() handling of gitmodules
> @@ Commit message
>
> Signed-off-by: Jeff King <peff@peff.net>
>
> - ## t/t7450-bad-meta-files.sh ##
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'index-pack --strict works for non-repo pack' '
> + ## t/t7450-bad-dotgitx-files.sh ##
> +@@ t/t7450-bad-dotgitx-files.sh: test_expect_success 'index-pack --strict works for non-repo pack' '
> grep gitmodulesName output
> '
>
> -test_expect_success 'fsck detects symlinked .gitmodules file' '
> -+test_expect_success 'create repo with symlinked .gitmodules file' '
> ++test_expect_success 'set up repo with symlinked .gitmodules file' '
> git init symlink &&
> (
> cd symlink &&
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'fsck detects symlinked .gitmodules file' '
> +@@ t/t7450-bad-dotgitx-files.sh: test_expect_success 'fsck detects symlinked .gitmodules file' '
> {
> printf "100644 blob $content\t$tricky\n" &&
> printf "120000 blob $target\t.gitmodules\n"
> @@ t/t7450-bad-meta-files.sh: test_expect_success 'fsck detects symlinked .gitmodul
> + cd symlink &&
>
> # Check not only that we fail, but that it is due to the
> - # symlink detector; this grep string comes from the config
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'fsck detects symlinked .gitmodules file' '
> + # symlink detector
> +@@ t/t7450-bad-dotgitx-files.sh: test_expect_success 'fsck detects symlinked .gitmodules file' '
> )
> '
>
> -+test_expect_success 'refuse to load symlinked .gitmodule into index' '
> ++test_expect_success 'refuse to load symlinked .gitmodules into index' '
> + test_must_fail git -C symlink read-tree $tree 2>err &&
> -+ test_i18ngrep "invalid path.*gitmodules" err
> ++ test_i18ngrep "invalid path.*gitmodules" err &&
> ++ git -C symlink ls-files >out &&
> ++ test_must_be_empty out
> +'
> +
> test_expect_success 'fsck detects non-blob .gitmodules' '
> -: ---------- > 5: db5e78ff5b t7450: test .gitmodules symlink matching against obscured names
> 5: e141e49a5b ! 6: b5962a75a4 t0060: test obscured .gitattributes and .gitignore matching
> @@ t/helper/test-path-utils.c: static struct test_data dirname_data[] = {
> + if (!strcmp("--not", *argv))
> + expect = !expect;
> + else if (expect != (is_hfs(*argv) || is_ntfs(*argv)))
> -+ res = error("'%s' is %s.%s", *argv,
> -+ expect ? "not " : "", x);
> ++ res = error("'%s' is %s.git%s", *argv,
> ++ expect ? "not " : "", x);
> + else
> -+ fprintf(stderr, "ok: '%s' is %s.%s\n",
> ++ fprintf(stderr, "ok: '%s' is %s.git%s\n",
> + *argv, expect ? "" : "not ", x);
> + }
> + return !!res;
> @@ t/helper/test-path-utils.c: int cmd__path_utils(int argc, const char **argv)
> - fprintf(stderr, "ok: '%s' is %s.gitmodules\n",
> - argv[i], expect ? "" : "not ");
> - return !!res;
> -+ return check_dotgitx("gitmodules", argv + 2,
> ++ return check_dotgitx("modules", argv + 2,
> + is_hfs_dotgitmodules,
> + is_ntfs_dotgitmodules);
> + }
> + if (argc > 2 && !strcmp(argv[1], "is_dotgitignore")) {
> -+ return check_dotgitx("gitignore", argv + 2,
> ++ return check_dotgitx("ignore", argv + 2,
> + is_hfs_dotgitignore,
> + is_ntfs_dotgitignore);
> + }
> + if (argc > 2 && !strcmp(argv[1], "is_dotgitattributes")) {
> -+ return check_dotgitx("gitattributes", argv + 2,
> ++ return check_dotgitx("attributes", argv + 2,
> + is_hfs_dotgitattributes,
> + is_ntfs_dotgitattributes);
> }
> 6: d214bbd8ec ! 7: e4ec698a5b verify_path(): disallow symlinks in .gitattributes and .gitignore
> @@ Commit message
> 0fc333ba20 (is_hfs_dotgit: match other .git files, 2018-05-02), which
> were done as part of the series touching .gitmodules.
>
> + No tests yet, as we'll add them in a subsequent patch once we have fsck
> + support, too.
> +
> Signed-off-by: Jeff King <peff@peff.net>
>
> ## read-cache.c ##
> @@ read-cache.c: int verify_path(const char *path, unsigned mode)
> return 0;
> }
> }
> -
> - ## t/t7450-bad-meta-files.sh ##
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'git dirs of sibling submodules must not be nested' '
> - test_i18ngrep "is inside git dir" err
> - '
> -
> -+test_expect_success 'create repo with symlinked .gitattributes file' '
> -+ git init symlink-attr &&
> -+ target=$(echo target | git -C symlink-attr hash-object -w --stdin) &&
> -+ tree=$(
> -+ printf "120000 blob $target\t.gitattributes\n" |
> -+ git -C symlink-attr mktree
> -+ )
> -+'
> -+
> -+test_expect_success 'refuse to load symlinked .gitattributes into index' '
> -+ test_must_fail git -C symlink-attr read-tree $tree 2>err &&
> -+ test_i18ngrep "invalid path.*gitattributes" err
> -+'
> -+
> -+test_expect_success 'create repo with symlinked .gitignore file' '
> -+ git init symlink-ignore &&
> -+ target=$(echo target | git -C symlink-ignore hash-object -w --stdin) &&
> -+ tree=$(
> -+ printf "120000 blob $target\t.gitignore\n" |
> -+ git -C symlink-ignore mktree
> -+ )
> -+'
> -+
> -+test_expect_success 'refuse to load symlinked .gitignore into index' '
> -+ test_must_fail git -C symlink-ignore read-tree $tree 2>err &&
> -+ test_i18ngrep "invalid path.*gitignore" err
> -+'
> -+
> -+
> - test_done
> 7: 49423d03b5 ! 8: 58c9ce0f3c fsck: complain when .gitattributes or .gitignore is a symlink
> @@ Commit message
> check to fsck, which matches how we handle .gitmodules symlinks, via
> b7b1fca175 (fsck: complain when .gitmodules is a symlink, 2018-05-04).
>
> - Note that we won't add these to the existing gitmodules block. Its logic
> - 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).
> + Note that we won't add these to the existing gitmodules block. 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 (and this covers the verify_path() change from the previous
> + commit, as well).
>
> Signed-off-by: Jeff King <peff@peff.net>
>
> @@ fsck.c: static int fsck_tree(const struct object_id *tree_oid,
> while (backslash) {
> backslash++;
>
> - ## t/t7450-bad-meta-files.sh ##
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'refuse to load symlinked .gitattributes into index' '
> - test_i18ngrep "invalid path.*gitattributes" err
> - '
> + ## t/t7450-bad-dotgitx-files.sh ##
> +@@ t/t7450-bad-dotgitx-files.sh: check_forbidden_symlink gitmodules vanilla .gitmodules
> + check_forbidden_symlink gitmodules ntfs ".gitmodules ."
> + check_forbidden_symlink gitmodules hfs ".${u200c}gitmodules"
>
> -+test_expect_success 'fsck detects symlinked .gitattributes file' '
> -+ test_must_fail git -C symlink-attr fsck 2>err &&
> -+ test_i18ngrep "tree $tree: gitattributesSymlink" err
> -+'
> ++check_forbidden_symlink gitattributes vanilla .gitattributes
> ++check_forbidden_symlink gitattributes ntfs ".gitattributes ."
> ++check_forbidden_symlink gitattributes hfs ".${u200c}gitattributes"
> +
> - test_expect_success 'create repo with symlinked .gitignore file' '
> - git init symlink-ignore &&
> - target=$(echo target | git -C symlink-ignore hash-object -w --stdin) &&
> -@@ t/t7450-bad-meta-files.sh: test_expect_success 'refuse to load symlinked .gitignore into index' '
> - test_i18ngrep "invalid path.*gitignore" err
> - '
> -
> -+test_expect_success 'fsck detects symlinked .gitignore file' '
> -+ test_must_fail git -C symlink-ignore fsck 2>err &&
> -+ test_i18ngrep "tree $tree: gitignoreSymlink" err
> -+'
> -
> - test_done
> ++check_forbidden_symlink gitignore vanilla .gitignore
> ++check_forbidden_symlink gitignore ntfs ".gitignore ."
> ++check_forbidden_symlink gitignore hfs ".${u200c}gitignore"
> ++
> + test_expect_success 'fsck detects non-blob .gitmodules' '
> + git init non-blob &&
> + (
^ permalink raw reply [flat|nested] 55+ messages in thread* [PATCH] documentation symlink restrictions for .git* files
2020-10-20 23:19 ` Philip Oakley
@ 2020-10-23 8:17 ` Jeff King
2020-10-23 8:27 ` Jeff King
2020-10-26 22:18 ` Philip Oakley
0 siblings, 2 replies; 55+ messages in thread
From: Jeff King @ 2020-10-23 8:17 UTC (permalink / raw)
To: Philip Oakley; +Cc: git, Jonathan Nieder
On Wed, Oct 21, 2020 at 12:19:25AM +0100, Philip Oakley wrote:
> On 05/10/2020 13:16, Jeff King wrote:
> > On Mon, Oct 05, 2020 at 03:17:51AM -0400, Jeff King wrote:
> >
> >> About 2 years ago as part of a security release we made it illegal to
> >> have a symlinked .gitmodules file (refusing it both in the index and via
> >> fsck). At the time we discussed (on the security list) outlawing
> >> symlinks for other .git files in the same way, but we decided not to do
> >> so as part of the security release, as it wasn't strictly necessary.
>
> Is this something that should be recorded in the documentation, either as a
> simple (sensible) limitation, or explicitly as a security related safety
> measure?
>
> I didn't see any changes to the .txt docs in the change list below.
Yeah, that's a good point.
How about this (on top of jk/symlinked-dotgitx-files)?
-- >8 --
Subject: [PATCH] documentation symlink restrictions for .git* files
We outlawed symbolic link versions of various .git files in 10ecfa7649
(verify_path: disallow symlinks in .gitmodules, 2018-05-04) and
dd4c2fe66b (verify_path(): disallow symlinks in .gitattributes and
.gitignore, 2020-10-05). The reasons are discussed in detail there, but
we never adjusted the documentation to let users know.
This hasn't been a big deal since the point is that such setups were
mildly broken and thought to be unusual anyway. But it certainly doesn't
hurt to be clear and explicit about it.
Suggested-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/gitattributes.txt | 7 +++++++
Documentation/gitignore.txt | 5 +++++
Documentation/gitmodules.txt | 8 ++++++++
3 files changed, 20 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2d0a03715b..9a2ce4f1ea 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -1241,6 +1241,13 @@ to:
[attr]binary -diff -merge -text
------------
+NOTES
+-----
+
+Note that Git does not allow a `.gitattributes` file within the working
+tree to be a symbolic link, and will refuse to check out such a tree
+entry. This keeps behavior consistent when the file is accessed from
+the index or a tree versus from the filesystem.
EXAMPLES
--------
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index d47b1ae296..7e9a1d49d6 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -149,6 +149,11 @@ not tracked by Git remain untracked.
To stop tracking a file that is currently tracked, use
'git rm --cached'.
+Note that Git does not allow a `.gitignore` file within the working tree
+to be a symbolic link, and will refuse to check out such a tree entry.
+This keeps behavior consistent when the file is accessed from the index
+or a tree versus from the filesystem.
+
EXAMPLES
--------
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 539b4e1997..2b884be3c7 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -98,6 +98,14 @@ submodule.<name>.shallow::
shallow clone (with a history depth of 1) unless the user explicitly
asks for a non-shallow clone.
+NOTES
+-----
+
+Note that Git does not allow the `.gitmodules` file within a working
+tree to be a symbolic link, and will refuse to check out such a tree
+entry. This keeps behavior consistent when the file is accessed from the
+index or a tree versus from the filesystem, and helps Git reliably
+enforce security checks of the file contents.
EXAMPLES
--------
--
2.29.0.583.g8e3ac41d8f
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-23 8:17 ` [PATCH] documentation symlink restrictions for .git* files Jeff King
@ 2020-10-23 8:27 ` Jeff King
2020-10-26 22:18 ` Philip Oakley
1 sibling, 0 replies; 55+ messages in thread
From: Jeff King @ 2020-10-23 8:27 UTC (permalink / raw)
To: Philip Oakley; +Cc: git, Jonathan Nieder
On Fri, Oct 23, 2020 at 04:17:11AM -0400, Jeff King wrote:
> Subject: [PATCH] documentation symlink restrictions for .git* files
Oops, that should be "document symlink" of course.
-Peff
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-23 8:17 ` [PATCH] documentation symlink restrictions for .git* files Jeff King
2020-10-23 8:27 ` Jeff King
@ 2020-10-26 22:18 ` Philip Oakley
2020-10-26 22:53 ` Jeff King
1 sibling, 1 reply; 55+ messages in thread
From: Philip Oakley @ 2020-10-26 22:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jonathan Nieder
On 23/10/2020 09:17, Jeff King wrote:
> On Wed, Oct 21, 2020 at 12:19:25AM +0100, Philip Oakley wrote:
>
>> On 05/10/2020 13:16, Jeff King wrote:
>>> On Mon, Oct 05, 2020 at 03:17:51AM -0400, Jeff King wrote:
>>>
>>>> About 2 years ago as part of a security release we made it illegal to
>>>> have a symlinked .gitmodules file (refusing it both in the index and via
>>>> fsck). At the time we discussed (on the security list) outlawing
>>>> symlinks for other .git files in the same way, but we decided not to do
>>>> so as part of the security release, as it wasn't strictly necessary.
>> Is this something that should be recorded in the documentation, either as a
>> simple (sensible) limitation, or explicitly as a security related safety
>> measure?
>>
>> I didn't see any changes to the .txt docs in the change list below.
> Yeah, that's a good point.
>
> How about this (on top of jk/symlinked-dotgitx-files)?
>
> -- >8 --
> Subject: [PATCH] documentation symlink restrictions for .git* files
>
> We outlawed symbolic link versions of various .git files in 10ecfa7649
> (verify_path: disallow symlinks in .gitmodules, 2018-05-04) and
> dd4c2fe66b (verify_path(): disallow symlinks in .gitattributes and
> .gitignore, 2020-10-05). The reasons are discussed in detail there, but
> we never adjusted the documentation to let users know.
>
> This hasn't been a big deal since the point is that such setups were
> mildly broken and thought to be unusual anyway. But it certainly doesn't
> hurt to be clear and explicit about it.
>
> Suggested-by: Philip Oakley <philipoakley@iee.email>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/gitattributes.txt | 7 +++++++
> Documentation/gitignore.txt | 5 +++++
> Documentation/gitmodules.txt | 8 ++++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 2d0a03715b..9a2ce4f1ea 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -1241,6 +1241,13 @@ to:
> [attr]binary -diff -merge -text
> ------------
>
> +NOTES
> +-----
> +
> +Note that Git does not allow a `.gitattributes` file within the working
> +tree to be a symbolic link, and will refuse to check out such a tree
> +entry. This keeps behavior consistent when the file is accessed from
> +the index or a tree versus from the filesystem.
>
> EXAMPLES
> --------
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index d47b1ae296..7e9a1d49d6 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -149,6 +149,11 @@ not tracked by Git remain untracked.
> To stop tracking a file that is currently tracked, use
> 'git rm --cached'.
>
> +Note that Git does not allow a `.gitignore` file within the working tree
> +to be a symbolic link, and will refuse to check out such a tree entry.
> +This keeps behavior consistent when the file is accessed from the index
> +or a tree versus from the filesystem.
> +
> EXAMPLES
> --------
>
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index 539b4e1997..2b884be3c7 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -98,6 +98,14 @@ submodule.<name>.shallow::
> shallow clone (with a history depth of 1) unless the user explicitly
> asks for a non-shallow clone.
>
> +NOTES
> +-----
> +
> +Note that Git does not allow the `.gitmodules` file within a working
> +tree to be a symbolic link, and will refuse to check out such a tree
> +entry. This keeps behavior consistent when the file is accessed from the
> +index or a tree versus from the filesystem, and helps Git reliably
> +enforce security checks of the file contents.
>
> EXAMPLES
> --------
The text looks good to me, with security point explicitly mentioned just
for .gitmodules file.
However, is placing the Note so far down appropriate (.gitattributes and
.gitignore), given that there is within the descriptions a discussion of
the priority order for finding those files?
Philip
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-26 22:18 ` Philip Oakley
@ 2020-10-26 22:53 ` Jeff King
2020-10-26 23:32 ` Junio C Hamano
0 siblings, 1 reply; 55+ messages in thread
From: Jeff King @ 2020-10-26 22:53 UTC (permalink / raw)
To: Philip Oakley; +Cc: git, Jonathan Nieder
On Mon, Oct 26, 2020 at 10:18:18PM +0000, Philip Oakley wrote:
> > +NOTES
> > +-----
> > +
> > +Note that Git does not allow the `.gitmodules` file within a working
> > +tree to be a symbolic link, and will refuse to check out such a tree
> > +entry. This keeps behavior consistent when the file is accessed from the
> > +index or a tree versus from the filesystem, and helps Git reliably
> > +enforce security checks of the file contents.
> >
> > EXAMPLES
> > --------
> The text looks good to me, with security point explicitly mentioned just
> for .gitmodules file.
>
> However, is placing the Note so far down appropriate (.gitattributes and
> .gitignore), given that there is within the descriptions a discussion of
> the priority order for finding those files?
Definitely a "NOTES" section should go in that spot, but possibly the
text should be in the "DESCRIPTION" section. I was worried about
cluttering that early part with a detail that most people wouldn't care
too much about.
Looks like my patch is in 'next'; do you want to propose a patch moving
it around on top?
-Peff
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-26 22:53 ` Jeff King
@ 2020-10-26 23:32 ` Junio C Hamano
2020-10-27 7:26 ` Jeff King
0 siblings, 1 reply; 55+ messages in thread
From: Junio C Hamano @ 2020-10-26 23:32 UTC (permalink / raw)
To: Jeff King; +Cc: Philip Oakley, git, Jonathan Nieder
Jeff King <peff@peff.net> writes:
> Definitely a "NOTES" section should go in that spot, but possibly the
> text should be in the "DESCRIPTION" section. I was worried about
> cluttering that early part with a detail that most people wouldn't care
> too much about.
>
> Looks like my patch is in 'next'; do you want to propose a patch moving
> it around on top?
It probably is possible to tweak the introductory text this way
without being unnecessarily loud and keep the NOTES section where it
is.
I personally found that the placement of new text was OK, but this
may be overly compensated by my tendency to discount things that we
have discussed recently, which our mind often consider (only for
relative a short moment) as more important than they are, relative
to other things in the same document.
Documentation/gitattributes.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git i/Documentation/gitattributes.txt w/Documentation/gitattributes.txt
index 2d0a03715b..fd2de7344a 100644
--- i/Documentation/gitattributes.txt
+++ w/Documentation/gitattributes.txt
@@ -13,8 +13,8 @@ $GIT_DIR/info/attributes, .gitattributes
DESCRIPTION
-----------
-A `gitattributes` file is a simple text file that gives
-`attributes` to pathnames.
+A `gitattributes` file is a simple text file (it cannot be a
+symbolic link to anything) that gives `attributes` to pathnames.
Each line in `gitattributes` file is of form:
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-26 23:32 ` Junio C Hamano
@ 2020-10-27 7:26 ` Jeff King
2020-10-27 18:45 ` Junio C Hamano
0 siblings, 1 reply; 55+ messages in thread
From: Jeff King @ 2020-10-27 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philip Oakley, git, Jonathan Nieder
On Mon, Oct 26, 2020 at 04:32:27PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Definitely a "NOTES" section should go in that spot, but possibly the
> > text should be in the "DESCRIPTION" section. I was worried about
> > cluttering that early part with a detail that most people wouldn't care
> > too much about.
> >
> > Looks like my patch is in 'next'; do you want to propose a patch moving
> > it around on top?
>
> It probably is possible to tweak the introductory text this way
> without being unnecessarily loud and keep the NOTES section where it
> is.
> [...]
> DESCRIPTION
> -----------
>
> -A `gitattributes` file is a simple text file that gives
> -`attributes` to pathnames.
> +A `gitattributes` file is a simple text file (it cannot be a
> +symbolic link to anything) that gives `attributes` to pathnames.
I worried that even a short mention like this would be distracting. Not
because it's so long, but because it's right there in the very first
sentence, and I really think this is a corner case that most people
would not even think about.
So it is helpful if you are looking for info on symlinks and these
files, but probably clutter if you are looking for something else.
I have to admit I don't feel all that strongly either way, though.
-Peff
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-27 7:26 ` Jeff King
@ 2020-10-27 18:45 ` Junio C Hamano
2020-10-27 21:00 ` Philip Oakley
0 siblings, 1 reply; 55+ messages in thread
From: Junio C Hamano @ 2020-10-27 18:45 UTC (permalink / raw)
To: Jeff King; +Cc: Philip Oakley, git, Jonathan Nieder
Jeff King <peff@peff.net> writes:
>> DESCRIPTION
>> -----------
>>
>> -A `gitattributes` file is a simple text file that gives
>> -`attributes` to pathnames.
>> +A `gitattributes` file is a simple text file (it cannot be a
>> +symbolic link to anything) that gives `attributes` to pathnames.
>
> I worried that even a short mention like this would be distracting. Not
> because it's so long, but because it's right there in the very first
> sentence, and I really think this is a corner case that most people
> would not even think about.
>
> So it is helpful if you are looking for info on symlinks and these
> files, but probably clutter if you are looking for something else.
>
> I have to admit I don't feel all that strongly either way, though.
I don't, either, and as I said, I found that the placement of new
text was OK.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-27 18:45 ` Junio C Hamano
@ 2020-10-27 21:00 ` Philip Oakley
2020-10-28 19:14 ` Junio C Hamano
0 siblings, 1 reply; 55+ messages in thread
From: Philip Oakley @ 2020-10-27 21:00 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: git, Jonathan Nieder
On 27/10/2020 18:45, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>>> DESCRIPTION
>>> -----------
>>>
>>> -A `gitattributes` file is a simple text file that gives
>>> -`attributes` to pathnames.
>>> +A `gitattributes` file is a simple text file (it cannot be a
>>> +symbolic link to anything) that gives `attributes` to pathnames.
>> I worried that even a short mention like this would be distracting. Not
>> because it's so long, but because it's right there in the very first
>> sentence, and I really think this is a corner case that most people
>> would not even think about.
>>
>> So it is helpful if you are looking for info on symlinks and these
>> files, but probably clutter if you are looking for something else.
>>
>> I have to admit I don't feel all that strongly either way, though.
> I don't, either, and as I said, I found that the placement of new
> text was OK.
>
>
I do think that the extra text above is the right thing to do.
We should be informing readers early about things that are expressly
prohibited.
Leaving just the note till nearly the end of the rather long
attributes/ignore man pages makes it very hard to discover for
frustrated users, which would accidentally reinforce the idea of the
docs being poor (rather than being focussed).
Philip
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] documentation symlink restrictions for .git* files
2020-10-27 21:00 ` Philip Oakley
@ 2020-10-28 19:14 ` Junio C Hamano
0 siblings, 0 replies; 55+ messages in thread
From: Junio C Hamano @ 2020-10-28 19:14 UTC (permalink / raw)
To: Philip Oakley; +Cc: Jeff King, git, Jonathan Nieder
Philip Oakley <philipoakley@iee.email> writes:
> On 27/10/2020 18:45, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>> DESCRIPTION
>>>> -----------
>>>>
>>>> -A `gitattributes` file is a simple text file that gives
>>>> -`attributes` to pathnames.
>>>> +A `gitattributes` file is a simple text file (it cannot be a
>>>> +symbolic link to anything) that gives `attributes` to pathnames.
>>> I worried that even a short mention like this would be distracting. Not
>>> because it's so long, but because it's right there in the very first
>>> sentence, and I really think this is a corner case that most people
>>> would not even think about.
>>>
>>> So it is helpful if you are looking for info on symlinks and these
>>> files, but probably clutter if you are looking for something else.
>>>
>>> I have to admit I don't feel all that strongly either way, though.
>> I don't, either, and as I said, I found that the placement of new
>> text was OK.
>>
>>
> I do think that the extra text above is the right thing to do.
>
> We should be informing readers early about things that are expressly
> prohibited.
It needs to be balanced, though. If it is so common a temptation
among readers to make a symbolic link out of the tracked contents,
perhaps it is worth telling them that they shouldn't do so, but I
just do not get the feeling that it is the case.
^ permalink raw reply [flat|nested] 55+ messages in thread