summaryrefslogtreecommitdiff
path: root/.gitignore
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2019-10-01 23:27:18 +0200
committerLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2019-12-05 15:36:51 +0100
commita8dee3ca610f5a1d403634492136c887f83b59d2 (patch)
tree3055874d4666b3364d15cc205dc36e9680f294d9 /.gitignore
parentprotect_ntfs: turn on NTFS protection by default (diff)
downloadtgif-a8dee3ca610f5a1d403634492136c887f83b59d2.tar.xz
Disallow dubiously-nested submodule git directories
Currently it is technically possible to let a submodule's git directory point right into the git dir of a sibling submodule. Example: the git directories of two submodules with the names `hippo` and `hippo/hooks` would be `.git/modules/hippo/` and `.git/modules/hippo/hooks/`, respectively, but the latter is already intended to house the former's hooks. In most cases, this is just confusing, but there is also a (quite contrived) attack vector where Git can be fooled into mistaking remote content for file contents it wrote itself during a recursive clone. Let's plug this bug. To do so, we introduce the new function `validate_submodule_git_dir()` which simply verifies that no git dir exists for any leading directories of the submodule name (if there are any). Note: this patch specifically continues to allow sibling modules names of the form `core/lib`, `core/doc`, etc, as long as `core` is not a submodule name. This fixes CVE-2019-1387. Reported-by: Nicolas Joly <Nicolas.Joly@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions