git/git-submodule.sh, branch v2.15.2

Sync with Git 2.13.7

2018-05-22T05:10:49Z

* maint-2.13: Git 2.13.7 verify_path: disallow symlinks in .gitmodules update-index: stat updated files earlier verify_dotfile: mention case-insensitivity in comment verify_path: drop clever fallthrough skip_prefix: add case-insensitive variant is_{hfs,ntfs}_dotgitmodules: add tests is_ntfs_dotgit: match other .git files is_hfs_dotgit: match other .git files is_ntfs_dotgit: use a size_t for traversing string submodule-config: verify submodule names as paths

submodule-config: verify submodule names as paths

2018-05-22T03:50:11Z

Submodule "names" come from the untrusted .gitmodules file, but we blindly append them to $GIT_DIR/modules to create our on-disk repo paths. This means you can do bad things by putting "../" into the name (among other things). Let's sanity-check these names to avoid building a path that can be exploited. There are two main decisions: 1. What should the allowed syntax be? It's tempting to reuse verify_path(), since submodule names typically come from in-repo paths. But there are two reasons not to: a. It's technically more strict than what we need, as we really care only about breaking out of the $GIT_DIR/modules/ hierarchy. E.g., having a submodule named "foo/.git" isn't actually dangerous, and it's possible that somebody has manually given such a funny name. b. Since we'll eventually use this checking logic in fsck to prevent downstream repositories, it should be consistent across platforms. Because verify_path() relies on is_dir_sep(), it wouldn't block "foo\..\bar" on a non-Windows machine. 2. Where should we enforce it? These days most of the .gitmodules reads go through submodule-config.c, so I've put it there in the reading step. That should cover all of the C code. We also construct the name for "git submodule add" inside the git-submodule.sh script. This is probably not a big deal for security since the name is coming from the user anyway, but it would be polite to remind them if the name they pick is invalid (and we need to expose the name-checker to the shell anyway for our test scripts). This patch issues a warning when reading .gitmodules and just ignores the related config entry completely. This will generally end up producing a sensible error, as it works the same as a .gitmodules file which is missing a submodule entry (so "submodule update" will barf, but "git clone --recurse-submodules" will print an error but not abort the clone. There is one minor oddity, which is that we print the warning once per malformed config key (since that's how the config subsystem gives us the entries). So in the new test, for example, the user would see three warnings. That's OK, since the intent is that this case should never come up outside of malicious repositories (and then it might even benefit the user to see the message multiple times). Credit for finding this vulnerability and the proof of concept from which the test script was adapted goes to Etienne Stalmans. Signed-off-by: Jeff King

Merge branch 'sb/submodule-parallel-update' into maint

2017-09-10T08:03:06Z

Code clean-up. * sb/submodule-parallel-update: submodule.sh: remove unused variable

submodule.sh: remove unused variable

2017-08-17T18:05:49Z

This could have been part of 48308681b0 (git submodule update: have a dedicated helper for cloning, 2016-02-29). Signed-off-by: Stefan Beller Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

scripts: use "git foo" not "git-foo"

2017-08-07T19:04:45Z

We want to make sure that people who copy & paste code would see fewer instances of "git-foo". The use of these dashed forms have been discouraged since v1.6.0 days. Signed-off-by: Michael Forney Signed-off-by: Junio C Hamano

add: warn when adding an embedded repository

2017-06-15T16:10:44Z

It's an easy mistake to add a repository inside another repository, like: git clone $url git add . The resulting entry is a gitlink, but there's no matching .gitmodules entry. Trying to use "submodule init" (or clone with --recursive) doesn't do anything useful. Prior to v2.13, such an entry caused git-submodule to barf entirely. In v2.13, the entry is considered "inactive" and quietly ignored. Either way, no clone of your repository can do anything useful with the gitlink without the user manually adding the submodule config. In most cases, the user probably meant to either add a real submodule, or they forgot to put the embedded repository in their .gitignore file. Let's issue a warning when we see this case. There are a few things to note: - the warning will go in the git-add porcelain; anybody wanting to do low-level manipulation of the index is welcome to create whatever funny states they want. - we detect the case by looking for a newly added gitlink; updates via "git add submodule" are perfectly reasonable, and this avoids us having to investigate .gitmodules entirely - there's a command-line option to suppress the warning. This is needed for git-submodule itself (which adds the entry before adding any submodule config), but also provides a mechanism for other scripts doing submodule-like things. We could make this a hard error instead of a warning. However, we do add lots of sub-repos in our test suite. It's not _wrong_ to do so. It just creates a state where users may be surprised. Pointing them in the right direction with a gentle hint is probably the best option. There is a config knob that can disable the (long) hint. But I intentionally omitted a config knob to disable the warning entirely. Whether the warning is sensible or not is generally about context, not about the user's preferences. If there's a tool or workflow that adds gitlinks without matching .gitmodules, it should probably be taught about the new command-line option, rather than blanket-disabling the warning. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

submodule: prevent backslash expantion in submodule names

2017-04-17T03:09:36Z

When attempting to add a submodule with backslashes in its name 'git submodule' fails in a funny way. We can see that some of the backslashes are expanded resulting in a bogus path: git -C main submodule add ../sub\\with\\backslash fatal: repository '/tmp/test/sub\witackslash' does not exist fatal: clone of '/tmp/test/sub\witackslash' into submodule path To solve this, convert calls to 'read' to 'read -r' in git-submodule.sh in order to prevent backslash expantion in submodule names. Reported-by: Joachim Durchholz Signed-off-by: Brandon Williams Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

submodule add: respect submodule.active and submodule..active

2017-03-18T16:51:23Z

In addition to adding submodule..url to the config, set submodule..active to true unless submodule.active is configured and the submodule's path matches the configured pathspec. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

submodule sync: use submodule--helper is-active

2017-03-17T18:06:09Z

Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

submodule sync: skip work for inactive submodules

2017-03-17T18:06:09Z

Sync does some work determining what URLs should be used for a submodule but then throws this work away if the submodule isn't active. Instead perform the activity check earlier and skip inactive submodule in order to avoid doing unnecessary work. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano