Re: [RFC] How to pass Git config command line instructions to Submodule commands?

From: Lars Schneider <larsxschneider@gmail.com>
Date: Apr 28, 2016, 11:06 UTC
Message-ID: <017AA7DB-5224-49C3-A4A6-6C93005BF006@gmail.com>
In-Reply-To: <20160425212449.GA7636@sigill.intra.peff.net>

Show 31 quoted lines

> On 25 Apr 2016, at 23:24, Jeff King <peff@peff.net> wrote:
> 
> On Mon, Apr 25, 2016 at 01:59:03PM -0700, Jacob Keller wrote:
> 
>>>> However, I noticed that git config command line instructions such as
>>>> "-c filter.lfs.smudge=" are not passed to Git submodule operations. Thus
>>>> this does not work as expected:
>>>> 
>>>>    git -c filter.lfs.smudge= -c filter.lfs.required=false clone --recursive <url> <path>
>>> 
>>> I have cc'd Jacob Keller, who authored origin/jk/submodule-c-credential,
>>> which does work in that area (deciding which config option to pass down
>>> into the submodule commands).
>>> 
>> 
>> This is a tricky question. The problem is that some configurations are
>> obviously not intended to go into the submodules, but determining how
>> is somewhat troublesome. There was some discussion on this previous
>> thread when we added support for credential options to pass through.
> 
> Right. I think it may be reasonable to pass through filter.* in the
> whitelist.  They are not activated without a matching .gitattributes
> entry in the repository (and people would generally configure them in
> their user-level ~/.gitconfig for that reason).
> 
> It does mean that somebody would be stuck who really wanted to run the
> smudge filter in their local repo, but for some reason not in the
> subrepos. I am trying to think of a case in which that might be
> security-relevant if you didn't trust the sub-repos[1]. But I really
> don't see it. The filter is arbitrary code, but that's specified by the
> user; we're just feeding it possibly untrusted blobs.

This looks like a very promising solution and I can't think of a security problem either (I checked the older thread [1] you referenced, too)!

I got my Git-LFS use case working with the patch below. For me it was necessary to export GIT_CONFIG_PARAMETERS to make it available to the Git process if the process is invoked as follows [2]:

(sanitize_submodule_env; cd "$sm_path" && git <something>")

Exporting the variable would not be necessary in this case:

(cd "$sm_path" && sanitize_submodule_env git <something>")

Unfortunately that does not work and I think the reason is that clear_local_git_env (invoked by sanitize_submodule_env) clears the $GIT_DIR, too.

If there is a reason against exporting GIT_CONFIG_PARAMETERS, then this would work, too:

(sanitize_submodule_env; cd "$sm_path" && GIT_CONFIG_PARAMETERS=$GIT_CONFIG_PARAMETERS git <something>)

Would the patch below be an acceptable solution?

Thanks, Lars

[1] http://thread.gmane.org/gmane.comp.version-control.git/264840 [2] https://github.com/git/git/blob/3ad15fd5e17bbb73fb1161ff4e9c3ed254d5b243/git-submodule.sh#L811

diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 3bd6883..9231089 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -129,6 +129,8 @@ static int submodule_config_ok(const char *var)
 {
 	if (starts_with(var, "credential."))
 		return 1;
+	if (starts_with(var, "filter."))
+		return 1;
 	return 0;
 }

diff --git a/git-submodule.sh b/git-submodule.sh
index 2a84d7e..b02f5b9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -199,7 +199,7 @@ sanitize_submodule_env()
 {
 	sanitized_config=$(git submodule--helper sanitize-config)
 	clear_local_git_env
-	GIT_CONFIG_PARAMETERS=$sanitized_config
+	export GIT_CONFIG_PARAMETERS=$sanitized_config
 }

 #