git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] submodule: stop sanitizing config options

From
Junio C Hamano <gitster@pobox.com>
Date
May 5, 2016, 16:59 UTC
Message-ID
<xmqq60uscufw.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160505012219.GA15090@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here's a version of my patch that should apply for you (no
> semantic changes, just differences in the surrounding context):
Sorry for the trouble.

I queued jk/submodule-c-credential to be mergeable to 'maint', as it could be argued two ways. We can say that not propagating -c down is a bug and the series is a bugfix. Or it is merely a known limitation and the series is a new feature. I was leaning towards the former, but I was also willing to declare that is a known bug that will left unfixed in the maintenance track.

If I knew the 5 patches on jk/submodule-config-sanitize-fix was what we would eventually agree to be the right change, I would have applied them directly on top of jk/submodule-c-credential instead of forking a separate branch for them. That way, either the "bugfix" would all go to 'maint', or the "feature" wouldn't, and we do not have to worry about making a mistake to merge only half-done state (i.e. jk/submodule-c-credential that passes only the credential.* configuration) that nobody would want to 'maint'.

But when I picked up jk/submodule-config-sanitize-fix, I didn't have enough time to think things through or carefully read the discussion to convince myself that we already had a list concensus, so I queued it separately only to make sure I won't lose track of it--I can come back to it later that way.

It probably is a good time to merge jk/submodule-config-sanitize-fix into jk/submodule-c-credential (i.e. a mere fast-forward), remove that "-fix" branch, and apply this patch directly on top of the resulting jk/submodule-c-credential. That will make the whole thing a 13-patch series, consisting of:

 7 patches up to the current jk/submodule-c-credential
  d1f8849 git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
  14111fc git: submodule honor -c credential.* from command line
  e70986d quote: implement sq_quotef()
  7dad263 submodule: fix segmentation fault in submodule--helper clone
  717416c submodule: fix submodule--helper clone usage
  08e0970 submodule: check argc count for git submodule--helper clone
  d10e3b4 submodule: don't pass empty string arguments to submodule--helper clone
 
 5 patches up to the current jk/submodule-config-sanitize-fix
  c12e865 submodule: use prepare_submodule_repo_env consistently
  4638728 submodule--helper: move config-sanitizing to submodule.c
  860cba6 submodule: export sanitized GIT_CONFIG_PARAMETERS
  455d22c t5550: break submodule config test into multiple sub-tests
  1149ee2 t5550: fix typo in $HTTPD_URL
 1 patch (this one)
  4e6706a submodule: stop sanitizing config options

whose early 7 patches have already been merged to 'master' (and none has been merged to 'maint').

Show 180 quoted lines
> -- >8 --
> Subject: [PATCH] submodule: stop sanitizing config options
>
> The point of having a whitelist of command-line config
> options to pass to submodules was two-fold:
>
>   1. It prevented obvious nonsense like using core.worktree
>      for multiple repos.
>
>   2. It could prevent surprise when the user did not mean
>      for the options to leak to the submodules (e.g.,
>      http.sslverify=false).
>
> For case 1, the answer is mostly "if it hurts, don't do
> that". For case 2, we can note that any such example has a
> matching inverted surprise (e.g., a user who meant
> http.sslverify=true to apply everywhere, but it didn't).
>
> So this whitelist is probably not giving us any benefit, and
> is already creating a hassle as people propose things to put
> on it. Let's just drop it entirely.
>
> Note that we still need to keep a special code path for
> "prepare the submodule environment", because we still have
> to take care to pass through $GIT_CONFIG_PARAMETERS (and
> block the rest of the repo-specific environment variables).
>
> We can do this easily from within the submodule shell
> script, which lets us drop the submodule--helper option
> entirely (and it's OK to do so because as a "--" program, it
> is entirely a private implementation detail).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  builtin/submodule--helper.c  | 17 -----------------
>  git-submodule.sh             |  4 ++--
>  submodule.c                  | 39 +--------------------------------------
>  t/t7412-submodule--helper.sh | 26 --------------------------
>  4 files changed, 3 insertions(+), 83 deletions(-)
>  delete mode 100755 t/t7412-submodule--helper.sh
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 16d6432..89250f0 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -260,22 +260,6 @@ static int module_clone(int argc, const char **argv, const char *prefix)
>  	return 0;
>  }
>  
> -static int module_sanitize_config(int argc, const char **argv, const char *prefix)
> -{
> -	struct strbuf sanitized_config = STRBUF_INIT;
> -
> -	if (argc > 1)
> -		usage(_("git submodule--helper sanitize-config"));
> -
> -	git_config_from_parameters(sanitize_submodule_config, &sanitized_config);
> -	if (sanitized_config.len)
> -		printf("%s\n", sanitized_config.buf);
> -
> -	strbuf_release(&sanitized_config);
> -
> -	return 0;
> -}
> -
>  struct cmd_struct {
>  	const char *cmd;
>  	int (*fn)(int, const char **, const char *);
> @@ -285,7 +269,6 @@ static struct cmd_struct commands[] = {
>  	{"list", module_list},
>  	{"name", module_name},
>  	{"clone", module_clone},
> -	{"sanitize-config", module_sanitize_config},
>  };
>  
>  int cmd_submodule__helper(int argc, const char **argv, const char *prefix)
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 91f5856..b1c056c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -197,9 +197,9 @@ isnumber()
>  # of the settings from GIT_CONFIG_PARAMETERS.
>  sanitize_submodule_env()
>  {
> -	sanitized_config=$(git submodule--helper sanitize-config)
> +	save_config=$GIT_CONFIG_PARAMETERS
>  	clear_local_git_env
> -	GIT_CONFIG_PARAMETERS=$sanitized_config
> +	GIT_CONFIG_PARAMETERS=$save_config
>  	export GIT_CONFIG_PARAMETERS
>  }
>  
> diff --git a/submodule.c b/submodule.c
> index c18ab9b..d598881 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1098,50 +1098,13 @@ void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir)
>  	strbuf_release(&rel_path);
>  	free((void *)real_work_tree);
>  }
> -/*
> - * Rules to sanitize configuration variables that are Ok to be passed into
> - * submodule operations from the parent project using "-c". Should only
> - * include keys which are both (a) safe and (b) necessary for proper
> - * operation.
> - */
> -static int submodule_config_ok(const char *var)
> -{
> -	if (starts_with(var, "credential."))
> -		return 1;
> -	return 0;
> -}
> -
> -int sanitize_submodule_config(const char *var, const char *value, void *data)
> -{
> -	struct strbuf *out = data;
> -
> -	if (submodule_config_ok(var)) {
> -		if (out->len)
> -			strbuf_addch(out, ' ');
> -
> -		if (value)
> -			sq_quotef(out, "%s=%s", var, value);
> -		else
> -			sq_quote_buf(out, var);
> -	}
> -
> -	return 0;
> -}
>  
>  void prepare_submodule_repo_env(struct argv_array *out)
>  {
>  	const char * const *var;
>  
>  	for (var = local_repo_env; *var; var++) {
> -		if (!strcmp(*var, CONFIG_DATA_ENVIRONMENT)) {
> -			struct strbuf sanitized_config = STRBUF_INIT;
> -			git_config_from_parameters(sanitize_submodule_config,
> -						   &sanitized_config);
> -			argv_array_pushf(out, "%s=%s", *var, sanitized_config.buf);
> -			strbuf_release(&sanitized_config);
> -		} else {
> +		if (strcmp(*var, CONFIG_DATA_ENVIRONMENT))
>  			argv_array_push(out, *var);
> -		}
>  	}
> -
>  }
> diff --git a/t/t7412-submodule--helper.sh b/t/t7412-submodule--helper.sh
> deleted file mode 100755
> index 149d428..0000000
> --- a/t/t7412-submodule--helper.sh
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -#!/bin/sh
> -#
> -# Copyright (c) 2016 Jacob Keller
> -#
> -
> -test_description='Basic plumbing support of submodule--helper
> -
> -This test verifies the submodule--helper plumbing command used to implement
> -git-submodule.
> -'
> -
> -. ./test-lib.sh
> -
> -test_expect_success 'sanitize-config clears configuration' '
> -	git -c user.name="Some User" submodule--helper sanitize-config >actual &&
> -	test_must_be_empty actual
> -'
> -
> -sq="'"
> -test_expect_success 'sanitize-config keeps credential.helper' '
> -	git -c credential.helper=helper submodule--helper sanitize-config >actual &&
> -	echo "${sq}credential.helper=helper${sq}" >expect &&
> -	test_cmp expect actual
> -'
> -
> -test_done
Previous: Jeff KingNext: Jeff King
Message 78 of 119 in “http: Support sending custom HTTP headers”
  1. http: Support sending custom HTTP headersJohannes Schindelin, Apr 25, 2016
  2. Shawn PearceApr 25, 2016
  3. Jeff KingApr 25, 2016
  4. Johannes SchindelinApr 26, 2016
  5. Jeff KingApr 26, 2016
  6. Junio C HamanoApr 25, 2016
  7. Johannes SchindelinApr 26, 2016
  8. Junio C HamanoApr 26, 2016
  9. Jeff KingApr 26, 2016
  10. Johannes SchindelinApr 27, 2016
  11. Jeff KingApr 27, 2016
  12. Johannes SchindelinApr 27, 2016
  13. http: support sending custom HTTP headersJohannes Schindelin, Apr 26, 2016
  14. Junio C HamanoApr 26, 2016
  15. Jeff KingApr 26, 2016
  16. Junio C HamanoApr 26, 2016
  17. Jeff KingApr 26, 2016
  18. Johannes SchindelinApr 27, 2016
  19. Johannes SchindelinApr 27, 2016
  20. Junio C HamanoApr 26, 2016
  21. http: support sending custom HTTP headersJohannes Schindelin, Apr 27, 2016
  22. http: support sending custom HTTP headersJohannes Schindelin, Apr 27, 2016
  23. Jeff KingApr 27, 2016
  24. Junio C HamanoApr 27, 2016
  25. 0/2 Add support for sending additional HTTP headersJohannes Schindelin, Apr 28, 2016
  26. 1/2 http: support sending custom HTTP headersJohannes Schindelin, Apr 28, 2016
  27. 2/2 submodule: pass on http.extraheader config settingsJohannes Schindelin, Apr 28, 2016
  28. Jeff KingApr 28, 2016
  29. Johannes SchindelinApr 28, 2016
  30. Jeff KingApr 28, 2016
  31. Jacob KellerApr 28, 2016
  32. Jeff KingApr 28, 2016
  33. Stefan BellerApr 28, 2016
  34. Jeff KingApr 28, 2016
  35. Junio C HamanoApr 28, 2016
  36. Jeff KingApr 28, 2016
  37. Junio C HamanoApr 28, 2016
  38. Stefan BellerApr 28, 2016
  39. Junio C HamanoApr 28, 2016
  40. Junio C HamanoApr 28, 2016
  41. Stefan BellerApr 28, 2016
  42. Junio C HamanoApr 28, 2016
  43. Jeff KingApr 28, 2016
  44. Stefan BellerApr 28, 2016
  45. Junio C HamanoApr 28, 2016
  46. Jeff KingApr 29, 2016
  47. Jeff KingApr 28, 2016
  48. Stefan BellerApr 28, 2016
  49. Jeff KingApr 28, 2016
  50. Johannes SchindelinApr 29, 2016
  51. Jeff KingApr 29, 2016
  52. Jeff KingApr 28, 2016
  53. Junio C HamanoApr 28, 2016
  54. Johannes SchindelinApr 29, 2016
  55. Johannes SchindelinApr 29, 2016
  56. Jeff KingApr 29, 2016
  57. Johannes SchindelinApr 29, 2016
  58. 0/2 Add support for sending additional HTTP headersJohannes Schindelin, May 4, 2016
  59. 1/2 http: support sending custom HTTP headersJohannes Schindelin, May 4, 2016
  60. Lars SchneiderMay 5, 2016
  61. Junio C HamanoMay 5, 2016
  62. Jeff KingMay 5, 2016
  63. 2/2 submodule: pass on http.extraheader config settingsJohannes Schindelin, May 4, 2016
  64. Jeff KingMay 4, 2016
  65. Junio C HamanoMay 4, 2016
  66. Johannes SchindelinMay 4, 2016
  67. Junio C HamanoMay 4, 2016
  68. Jeff KingMay 4, 2016
  69. submodule: stop sanitizing config optionsJeff King, May 4, 2016
  70. Junio C HamanoMay 4, 2016
  71. Johannes SchindelinMay 4, 2016
  72. Stefan BellerMay 4, 2016
  73. Jeff KingMay 4, 2016
  74. Junio C HamanoMay 4, 2016
  75. Jeff KingMay 4, 2016
  76. Stefan BellerMay 4, 2016
  77. Jeff KingMay 5, 2016
  78. Junio C HamanoMay 5, 2016
  79. Jeff KingMay 5, 2016
  80. Junio C HamanoMay 5, 2016
  81. Stefan BellerMay 6, 2016
  82. Jeff KingMay 6, 2016
  83. Junio C HamanoMay 6, 2016
  84. 0/3 Add support for sending additional HTTP headers (part 2)Johannes Schindelin, May 9, 2016
  85. 1/3 tests: Adjust the configuration for Apache 2.2Johannes Schindelin, May 9, 2016
  86. Jeff KingMay 9, 2016
  87. Johannes SchindelinMay 9, 2016
  88. Jeff KingMay 9, 2016
  89. Johannes SchindelinMay 9, 2016
  90. Junio C HamanoMay 9, 2016
  91. Jeff KingMay 9, 2016
  92. Junio C HamanoMay 9, 2016
  93. Johannes SchindelinMay 10, 2016
  94. Junio C HamanoMay 10, 2016
  95. Junio C HamanoMay 9, 2016
  96. Lars SchneiderMay 10, 2016
  97. Junio C HamanoMay 10, 2016
  98. 2/3 t5551: make the test for extra HTTP headers more robustJohannes Schindelin, May 9, 2016
  99. Lars SchneiderMay 9, 2016
  100. Jeff KingMay 9, 2016
  101. Johannes SchindelinMay 9, 2016
  102. Jeff KingMay 9, 2016
  103. 3/3 submodule: pass on http.extraheader config settingsJohannes Schindelin, May 9, 2016
  104. 0/3 Add support for sending additional HTTP headers (part 2)Johannes Schindelin, May 10, 2016
  105. 1/3 tests: adjust the configuration for Apache 2.2Johannes Schindelin, May 10, 2016
  106. Junio C HamanoMay 10, 2016
  107. 2/3 t5551: make the test for extra HTTP headers more robustJohannes Schindelin, May 10, 2016
  108. Junio C HamanoMay 10, 2016
  109. t5551 hangs ?Torsten Bögershausen, May 11, 2016
  110. Jeff KingMay 11, 2016
  111. Torsten BögershausenMay 11, 2016
  112. Jeff KingMay 12, 2016
  113. Torsten BögershausenMay 12, 2016
  114. Jeff KingMay 12, 2016
  115. Jeff KingMay 12, 2016
  116. 3/3 submodule: ensure that -c http.extraheader is heededJohannes Schindelin, May 10, 2016
  117. Junio C HamanoMay 10, 2016
  118. Johannes SchindelinMay 11, 2016
  119. mail-patch-series.sh, was Re: [PATCH v7 0/3] Add support for sending additional HTTP headers (part 2)Johannes Schindelin, May 16, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.