tree 7f74de00d1a43ca435b6af0b60ac0985cb8d82d8
parent 1742900c4cce993203d088f16a751073547ec350
author Jonathan Nieder <jrnieder@gmail.com> 1575538108 -0800
committer Jonathan Nieder <jrnieder@gmail.com> 1575964695 +0000

submodule: reject submodule.update = !command in .gitmodules

commit e904deb89d9a9669a76a426182506a084d3f6308 upstream.

Since ac1fbbda2013 (submodule: do not copy unknown update mode from
.gitmodules, 2013-12-02), Git has been careful to avoid copying

	[submodule "foo"]
		update = !run an arbitrary scary command

from .gitmodules to a repository's local config, copying in the
setting 'update = none' instead.  The gitmodules(5) manpage documents
the intention:

	The !command form is intentionally ignored here for security
	reasons

Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9
(submodule--helper: introduce new update-module-mode helper,
2018-08-13, first released in v2.20.0-rc0)), there are scenarios where
we *don't* ignore it: if the config store contains no
submodule.foo.update setting, the submodule-config API falls back to
reading .gitmodules and the repository-supplied !command gets run
after all.

This was part of a general change over time in submodule support to
read more directly from .gitmodules, since unlike .git/config it
allows a project to change values between branches and over time
(while still allowing .git/config to override things).  But it was
never intended to apply to this kind of dangerous configuration.

The behavior change was not advertised in ee69b2a9's commit message
and was missed in review.

Let's take the opportunity to make the protection more robust, even in
Git versions that are technically not affected: instead of quietly
converting 'update = !command' to 'update = none', noisily treat it as
an error.  Allowing the setting but treating it as meaning something
else was just confusing; users are better served by seeing the error
sooner.  Forbidding the construct makes the semantics simpler and
means we can check for it in fsck (in a separate patch).

As a result, the submodule-config API cannot read this value from
.gitmodules under any circumstance, and we can declare with confidence

	For security reasons, the '!command' form is not accepted
	here.

[jn: backported to 2.11.y:
 - allow submodule-config to read !command after all, since
   v2.15.0-rc0~120^2~10 (submodule--helper: don't overlay config in
   update-clone, 2017-08-03) hasn't happened yet
 - move the code to error out when "git submodule init" encounters
   !command in .gitmodules to module_init()
 - cmd_update in git-submodule.sh is responsible for reading the
   update strategy since v2.20.0-rc0~247^2 (submodule--helper:
   introduce update-module-mode, 2018-08-13) hasn't happened yet.
   cmd_update checks config directly and does not read .gitmodules,
   so we don't have to change it.  Accordingly, t7406 also does
   not need to change its expectation from ignoring to rejecting
   commands from .gitmodules.]

Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>