[PATCH 0/3] Sanitize sideband channel messages

[PATCH 0/3] Sanitize sideband channel messages

[Johannes Schindelin via GitGitGadget]

When a clone fails, users naturally turn to the output of the git
clone command. To assist in such scenarios, the output includes the messages
from the remote git pack-objects process, delivered via what Git calls the
"sideband channel."

Given that the remote server is, by nature, remote, there is no guarantee
that it runs an unmodified Git version. This exposes Git to ANSI escape
sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which can corrupt
terminal state, hide information, and even insert characters into the input
buffer (as if the user had typed those characters).

This patch series addresses this vulnerability by sanitizing the sideband
channel.

It is important to note that the lack of sanitization in the sideband
channel is already "exploited" by the Git user community, albeit in
well-intentioned ways. For instance, certain server-side hooks use ANSI
color sequences in error messages to make them more noticeable during
intentional failed fetches, e.g. as seen at
https://github.com/kikeonline/githook-explode and
https://github.com/arosien/bart/blob/HEAD/hooks/post-receive.php

To accommodate such use cases, Git will allow ANSI color sequences to pass
through by default, while presenting all other ASCII control characters in a
common form (e.g., presenting the ESC character as ^[).

This vulnerability was reported to the Git security mailing list in early
November, along with these fixes, as part of an iteration of the patches
that led to the coordinated security release on Tuesday, January 14th, 2025.

While Git for Windows included these fixes in v2.47.1(2), the consensus,
apart from one reviewer, was not to include them in Git's embargoed
versions. The risk was considered too high to disrupt existing scenarios
that depend on control characters received via the sideband channel being
sent verbatim to the user's terminal emulator.

Several reviewers suggested advising terminal emulator writers about these
"quality of implementation issues" instead. I was quite surprised by this
approach, as it seems overly optimistic to assume that terminal emulators
could distinguish between control characters intentionally sent by Git and
those unintentionally relayed from the remote server.

Please note that this patch series applies cleanly on top of v2.47.2. To
apply it cleanly on top of v2.40.4 (the oldest of the most recently serviced
security releases), the calls to test_grep need to be replaced with calls
to test_i18ngrep, and the calls to git_config_get_string_tmp() need to be
replaced with calls to git_config_get_string().

Johannes Schindelin (3):
  sideband: mask control characters
  sideband: introduce an "escape hatch" to allow control characters
  sideband: do allow ANSI color sequences by default

 Documentation/config.txt            |  2 +
 Documentation/config/sideband.txt   | 16 ++++++
 sideband.c                          | 78 ++++++++++++++++++++++++++++-
 t/t5409-colorize-remote-messages.sh | 30 +++++++++++
 4 files changed, 124 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/config/sideband.txt


base-commit: e1fbebe347426ef7974dc2198f8a277b7c31c8fe
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1853/dscho/sanitize-sideband-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1853
-- 
gitgitgadget

[PATCH 1/3] sideband: mask control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The output of `git clone` is a vital component for understanding what
has happened when things go wrong. However, these logs are partially
under the control of the remote server (via the "sideband", which
typically contains what the remote `git pack-objects` process sends to
`stderr`), and is currently not sanitized by Git.

This makes Git susceptible to ANSI escape sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
attackers to corrupt terminal state, to hide information, and even to
insert characters into the input buffer (i.e. as if the user had typed
those characters).

To plug this vulnerability, disallow any control character in the
sideband, replacing them instead with the common `^<letter/symbol>`
(e.g. `^[` for `\x1b`, `^A` for `\x01`).

There is likely a need for more fine-grained controls instead of using a
"heavy hammer" like this, which will be introduced subsequently.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 sideband.c                          | 17 +++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 12 ++++++++++++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/sideband.c b/sideband.c
index 02805573fab..c0b1cb044a3 100644
--- a/sideband.c
+++ b/sideband.c
@@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
+{
+	strbuf_grow(dest, n);
+	for (; n && *src; src++, n--) {
+		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
+			strbuf_addch(dest, *src);
+		else {
+			strbuf_addch(dest, '^');
+			strbuf_addch(dest, 0x40 + *src);
+		}
+	}
+}
+
 /*
  * Optionally highlight one keyword in remote output if it appears at the start
  * of the line. This should be called for a single line only, which is
@@ -80,7 +93,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 	int i;
 
 	if (!want_color_stderr(use_sideband_colors())) {
-		strbuf_add(dest, src, n);
+		strbuf_add_sanitized(dest, src, n);
 		return;
 	}
 
@@ -113,7 +126,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 		}
 	}
 
-	strbuf_add(dest, src, n);
+	strbuf_add_sanitized(dest, src, n);
 }
 
 
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 516b22fd963..61126e2b167 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -99,4 +99,16 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+test_expect_success 'disallow (color) control sequences in sideband' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
+	test_commit need-at-least-one-commit &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep ! RED decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH 2/3] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding commit fixed the vulnerability whereas sideband messages
(that are under the control of the remote server) could contain ANSI
escape sequences that would be sent to the terminal verbatim.

However, this fix may not be desirable under all circumstances, e.g.
when remote servers deliberately add coloring to their messages to
increase their urgency.

To help with those use cases, give users a way to opt-out of the
protections: `sideband.allowControlCharacters`.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config.txt            |  2 ++
 Documentation/config/sideband.txt   |  5 +++++
 sideband.c                          | 10 ++++++++++
 t/t5409-colorize-remote-messages.sh |  8 +++++++-
 4 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/config/sideband.txt

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8c0b3ed8075..48870bb588e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -522,6 +522,8 @@ include::config/sequencer.txt[]
 
 include::config/showbranch.txt[]
 
+include::config/sideband.txt[]
+
 include::config/sparse.txt[]
 
 include::config/splitindex.txt[]
diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
new file mode 100644
index 00000000000..3fb5045cd79
--- /dev/null
+++ b/Documentation/config/sideband.txt
@@ -0,0 +1,5 @@
+sideband.allowControlCharacters::
+	By default, control characters that are delivered via the sideband
+	are masked, to prevent potentially unwanted ANSI escape sequences
+	from being sent to the terminal. Use this config setting to override
+	this behavior.
diff --git a/sideband.c b/sideband.c
index c0b1cb044a3..b38a869c7b5 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,6 +25,8 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
+static int allow_control_characters;
+
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
 {
@@ -38,6 +40,9 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
+	git_config_get_bool("sideband.allowcontrolcharacters",
+			    &allow_control_characters);
+
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
 	else if (!git_config_get_string_tmp("color.ui", &value))
@@ -67,6 +72,11 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
+	if (allow_control_characters) {
+		strbuf_add(dest, src, n);
+		return;
+	}
+
 	strbuf_grow(dest, n);
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 61126e2b167..5806e5a67b3 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -106,9 +106,15 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	EOF
 	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
+
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep ! RED decoded
+	test_grep ! RED decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep RED decoded
 '
 
 test_done
-- 
gitgitgadget

[PATCH 3/3] sideband: do allow ANSI color sequences by default

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding two commits introduced special handling of the sideband
channel to neutralize ANSI escape sequences before sending the payload
to the terminal, and `sideband.allowControlCharacters` to override that
behavior.

However, some `pre-receive` hooks that are actively used in practice
want to color their messages and therefore rely on the fact that Git
passes them through to the terminal.

In contrast to other ANSI escape sequences, it is highly unlikely that
coloring sequences can be essential tools in attack vectors that mislead
Git users e.g. by hiding crucial information.

Therefore we can have both: Continue to allow ANSI coloring sequences to
be passed to the terminal, and neutralize all other ANSI escape
sequences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   | 17 ++++++--
 sideband.c                          | 61 ++++++++++++++++++++++++++---
 t/t5409-colorize-remote-messages.sh | 16 +++++++-
 3 files changed, 84 insertions(+), 10 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 3fb5045cd79..f347fd6b330 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -1,5 +1,16 @@
 sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
-	are masked, to prevent potentially unwanted ANSI escape sequences
-	from being sent to the terminal. Use this config setting to override
-	this behavior.
+	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal. Use
+	this config setting to override this behavior:
++
+--
+	color::
+		Allow ANSI color sequences, line feeds and horizontal tabs,
+		but mask all other control characters. This is the default.
+	false::
+		Mask all control characters other than line feeds and
+		horizontal tabs.
+	true::
+		Allow all control characters to be sent to the terminal.
+--
diff --git a/sideband.c b/sideband.c
index b38a869c7b5..9763dea0531 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,7 +25,11 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
-static int allow_control_characters;
+static enum {
+	ALLOW_NO_CONTROL_CHARACTERS = 0,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1,
+	ALLOW_ANSI_COLOR_SEQUENCES = 2
+} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -40,8 +44,24 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	git_config_get_bool("sideband.allowcontrolcharacters",
-			    &allow_control_characters);
+	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
+	case 0: /* Boolean value */
+		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
+			ALLOW_NO_CONTROL_CHARACTERS;
+		break;
+	case -1: /* non-Boolean value */
+		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
+					      &value))
+			; /* huh? `get_maybe_bool()` returned -1 */
+		else if (!strcmp(value, "color"))
+			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+		break;
+	default:
+		break; /* not configured */
+	}
 
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
@@ -70,9 +90,37 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+{
+	int i;
+
+	/*
+	 * Valid ANSI color sequences are of the form
+	 *
+	 * ESC [ [<n> [; <n>]*] m
+	 */
+
+	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
+	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+		return 0;
+
+	for (i = 2; i < n; i++) {
+		if (src[i] == 'm') {
+			strbuf_add(dest, src, i + 1);
+			return i;
+		}
+		if (!isdigit(src[i]) && src[i] != ';')
+			break;
+	}
+
+	return 0;
+}
+
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
-	if (allow_control_characters) {
+	int i;
+
+	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -81,7 +129,10 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
 			strbuf_addch(dest, *src);
-		else {
+		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+			src += i;
+			n -= i;
+		} else {
 			strbuf_addch(dest, '^');
 			strbuf_addch(dest, 0x40 + *src);
 		}
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 5806e5a67b3..98c575e2e7f 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -101,7 +101,7 @@ test_expect_success 'fallback to color.ui' '
 
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
-	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
 	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
@@ -109,12 +109,24 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
+	test_grep RED decoded &&
+	test_grep "\\^G" stderr &&
+	tr -dc "\\007" <stderr >actual &&
+	test_must_be_empty actual &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=false \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
 	test_grep ! RED decoded &&
+	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
 	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep RED decoded
+	test_grep RED decoded &&
+	tr -dc "\\007" <stderr >actual &&
+	test_file_not_empty actual
 '
 
 test_done
-- 
gitgitgadget

Re: [PATCH 0/3] Sanitize sideband channel messages

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 5777 bytes --]

On 2025-01-14 at 18:19:29, Johannes Schindelin via GitGitGadget wrote:
> When a clone fails, users naturally turn to the output of the git
> clone command. To assist in such scenarios, the output includes the messages
> from the remote git pack-objects process, delivered via what Git calls the
> "sideband channel."
> 
> Given that the remote server is, by nature, remote, there is no guarantee
> that it runs an unmodified Git version. This exposes Git to ANSI escape
> sequence injection (see
> CWE-150, https://cwe.mitre.org/data/definitions/150.html), which can corrupt
> terminal state, hide information, and even insert characters into the input
> buffer (as if the user had typed those characters).

I could certainly be mistaken, but I believe the report feature (e.g.,
title report), which is disabled for security reasons on all major
terminal emulators, is the only feature that can be used to adjust the
input buffer.  If there are others, then those would definitely be
vulnerability in the terminal emulator, which is the place they should be
fixed.

> This patch series addresses this vulnerability by sanitizing the sideband
> channel.
> 
> It is important to note that the lack of sanitization in the sideband
> channel is already "exploited" by the Git user community, albeit in
> well-intentioned ways. For instance, certain server-side hooks use ANSI
> color sequences in error messages to make them more noticeable during
> intentional failed fetches, e.g. as seen at
> https://github.com/kikeonline/githook-explode and
> https://github.com/arosien/bart/blob/HEAD/hooks/post-receive.php
> 
> To accommodate such use cases, Git will allow ANSI color sequences to pass
> through by default, while presenting all other ASCII control characters in a
> common form (e.g., presenting the ESC character as ^[).
> 
> This vulnerability was reported to the Git security mailing list in early
> November, along with these fixes, as part of an iteration of the patches
> that led to the coordinated security release on Tuesday, January 14th, 2025.

I think there is some disagreement as to whether this constitutes a
vulnerability.  I personally don't agree with that characterization, and
a CWE is a type of weakness, not a vulnerability.

Note that all of these problems could also occur by SSHing into an
untrusted server, running `curl` without redirecting output, or running
`cat` on a specially crafted file at the command line.  It is
specifically expected that people use SSH to log into untrusted or
partially-trusted machines, so this is not just a thought exercise.
None of those cases would be addressed by this series.

> While Git for Windows included these fixes in v2.47.1(2), the consensus,
> apart from one reviewer, was not to include them in Git's embargoed
> versions. The risk was considered too high to disrupt existing scenarios
> that depend on control characters received via the sideband channel being
> sent verbatim to the user's terminal emulator.
> 
> Several reviewers suggested advising terminal emulator writers about these
> "quality of implementation issues" instead. I was quite surprised by this
> approach, as it seems overly optimistic to assume that terminal emulators
> could distinguish between control characters intentionally sent by Git and
> those unintentionally relayed from the remote server.

I've done some analysis of this approach after discussion on the
security list and I don't think we should adopt it, as I mentioned
there.

Where pre-receive hooks are available, people frequently run various
commands to test and analyze code in them, including build or static
analysis tools, such as Rust's Cargo.  Cargo is capable of printing a
wide variety of escape sequences in its output, including `\e[K`, which
overwrites text to the right (e.g., for progress bars and status output
much like Git produces), and sequences for hyperlinks.  Stripping these
sequences would break the output in ways that would be confusing to the
user (since they work fine in a regular terminal) and hard to
reproduce or fix.

There are a variety of other terminal sequences that I have also seen
practically used here which would also be broken.  Other sequences that
could usefully be sent (but I have not seen practically implemented)
include sixel codes (which are a type of image format) that could be
used to display QR codes for purposes such as tracking CI jobs or
providing a "receipt" of code pushed.

I agree that this would have been a nice feature to add at the beginning
of the development of the sideband feature, but I fear that it is too
late to make an incompatible change now.

I realize that you've provided an escape hatch, but as we've seen with
other defense-in-depth measures, that doesn't avoid the inconvenience
and hassle of dealing with those changes and the costs of deploying
fixes everywhere.  We need to consider the costs and impact of these
patches on our users, including the burden of dealing with incompatible
changes, and given the fact that this problem can occur in a wide
variety of other contexts which you are not solving here and which would
be better solved more generally in terminal emulators themselves, I
don't think the benefits of this approach outweigh the downsides.

I do agree that there are terminal emulators which have some surprising
and probably insecure behaviour, as we've discussed in the past, but
because I believe those issues are more general and could be a problem
for any terminal-using program, I continue to believe that those issues
are best addressed in the terminal emulator itself.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH 1/3] sideband: mask control characters

[Phillip Wood]

Hi Dscho

Just a couple of small comments

On 14/01/2025 18:19, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
> +{
> +	strbuf_grow(dest, n);
> +	for (; n && *src; src++, n--) {
> +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')

Isn't it a bug to pass '\n' to maybe_colorize_sideband() ?

> +			strbuf_addch(dest, *src);
> +		else {
> +			strbuf_addch(dest, '^');
> +			strbuf_addch(dest, 0x40 + *src);

This will escape DEL ('\x7f') as "^\xbf" which is invalid in utf-8 
locales. Perhaps we could use "^?" for that instead.

> +test_expect_success 'disallow (color) control sequences in sideband' '
> +	write_script .git/color-me-surprised <<-\EOF &&
> +	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
> +	exec "$@"
> +	EOF
> +	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
> +	test_commit need-at-least-one-commit &&
> +	git clone --no-local . throw-away 2>stderr &&
> +	test_decode_color <stderr >decoded &&
> +	test_grep ! RED decoded

I'd be happier if we used test_cmp() here so that we check that the 
sanitized version matches what we expect and the test does not pass if 
there a typo in the script above stops it from writing the SGR code for red.

Best Wishes

Phillip

Re: [PATCH 0/3] Sanitize sideband channel messages

[Phillip Wood]

Hi Dscho

On 14/01/2025 18:19, Johannes Schindelin via GitGitGadget wrote:
> When a clone fails, users naturally turn to the output of the git
> clone command. To assist in such scenarios, the output includes the messages
> from the remote git pack-objects process, delivered via what Git calls the
> "sideband channel."
> 
> Given that the remote server is, by nature, remote, there is no guarantee
> that it runs an unmodified Git version. This exposes Git to ANSI escape
> sequence injection (see
> CWE-150, https://cwe.mitre.org/data/definitions/150.html), which can corrupt
> terminal state, hide information,

I agree we should think about preventing an untrusted remote process 
from making it look like its messages come from the trusted local 
process. At best it is confusing and at worst it might trick a user into 
running a malicious command if they think the message came from the 
local git process. We need to be careful not to break existing 
legitimate output though. Brian has already highlighted the need to 
support '\e[K' (clear to the end of the current line), we may also want 
to treat '\e[G' (move to column 1 on the current line) as '\r' in 
addition to SGR escapes in the last patch.

> and even insert characters into the input
> buffer (as if the user had typed those characters).

Maybe I've missed something but my understanding from the link above is 
that this is a non-issue for terminal emulators released in the last 20 
years. In any case I think that that is a security bug in the emulator 
and should be fixed there as it has been in the past. I found [1] to be 
much more informative than the mitre link above about the actual 
vulnerabilities.

Best Wishes

Phillip

[1] https://marc.info/?l=bugtraq&m=104612710031920

> This patch series addresses this vulnerability by sanitizing the sideband
> channel.
> 
> It is important to note that the lack of sanitization in the sideband
> channel is already "exploited" by the Git user community, albeit in
> well-intentioned ways. For instance, certain server-side hooks use ANSI
> color sequences in error messages to make them more noticeable during
> intentional failed fetches, e.g. as seen at
> https://github.com/kikeonline/githook-explode and
> https://github.com/arosien/bart/blob/HEAD/hooks/post-receive.php
> 
> To accommodate such use cases, Git will allow ANSI color sequences to pass
> through by default, while presenting all other ASCII control characters in a
> common form (e.g., presenting the ESC character as ^[).
> 
> This vulnerability was reported to the Git security mailing list in early
> November, along with these fixes, as part of an iteration of the patches
> that led to the coordinated security release on Tuesday, January 14th, 2025.
> 
> While Git for Windows included these fixes in v2.47.1(2), the consensus,
> apart from one reviewer, was not to include them in Git's embargoed
> versions. The risk was considered too high to disrupt existing scenarios
> that depend on control characters received via the sideband channel being
> sent verbatim to the user's terminal emulator.
> 
> Several reviewers suggested advising terminal emulator writers about these
> "quality of implementation issues" instead. I was quite surprised by this
> approach, as it seems overly optimistic to assume that terminal emulators
> could distinguish between control characters intentionally sent by Git and
> those unintentionally relayed from the remote server.
> 
> Please note that this patch series applies cleanly on top of v2.47.2. To
> apply it cleanly on top of v2.40.4 (the oldest of the most recently serviced
> security releases), the calls to test_grep need to be replaced with calls
> to test_i18ngrep, and the calls to git_config_get_string_tmp() need to be
> replaced with calls to git_config_get_string().
> 
> Johannes Schindelin (3):
>    sideband: mask control characters
>    sideband: introduce an "escape hatch" to allow control characters
>    sideband: do allow ANSI color sequences by default
> 
>   Documentation/config.txt            |  2 +
>   Documentation/config/sideband.txt   | 16 ++++++
>   sideband.c                          | 78 ++++++++++++++++++++++++++++-
>   t/t5409-colorize-remote-messages.sh | 30 +++++++++++
>   4 files changed, 124 insertions(+), 2 deletions(-)
>   create mode 100644 Documentation/config/sideband.txt
> 
> 
> base-commit: e1fbebe347426ef7974dc2198f8a277b7c31c8fe
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1853/dscho/sanitize-sideband-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1853

Re: [PATCH 1/3] sideband: mask control characters

[Andreas Schwab]

On Jan 14 2025, Johannes Schindelin via GitGitGadget wrote:

> diff --git a/sideband.c b/sideband.c
> index 02805573fab..c0b1cb044a3 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
>  		list_config_item(list, prefix, keywords[i].keyword);
>  }
>  
> +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
> +{
> +	strbuf_grow(dest, n);
> +	for (; n && *src; src++, n--) {
> +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')

The argument of iscntrl needs to be converted to unsigned char.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 1/3] sideband: mask control characters

[Junio C Hamano]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Jan 14 2025, Johannes Schindelin via GitGitGadget wrote:
>
>> diff --git a/sideband.c b/sideband.c
>> index 02805573fab..c0b1cb044a3 100644
>> --- a/sideband.c
>> +++ b/sideband.c
>> @@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
>>  		list_config_item(list, prefix, keywords[i].keyword);
>>  }
>>  
>> +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
>> +{
>> +	strbuf_grow(dest, n);
>> +	for (; n && *src; src++, n--) {
>> +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
>
> The argument of iscntrl needs to be converted to unsigned char.

If this were system-provided one, you are absolutely correct.

But I think this comes from 

sane-ctype.h:15:#undef iscntrl
sane-ctype.h:40:#define iscntrl(x) (sane_istest(x,GIT_CNTRL))

and sane_istest() does the casting to uchar for us, so this may be
OK (even if it may be a bit misleading).

Re: [PATCH 0/3] Sanitize sideband channel messages

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Where pre-receive hooks are available, people frequently run various
> commands to test and analyze code in them, including build or static
> analysis tools, such as Rust's Cargo.  Cargo is capable of printing a
> wide variety of escape sequences in its output, including `\e[K`, which
> overwrites text to the right (e.g., for progress bars and status output
> much like Git produces), and sequences for hyperlinks.  Stripping these
> sequences would break the output in ways that would be confusing to the
> user (since they work fine in a regular terminal) and hard to
> reproduce or fix.

You have ruled out the attack vector that lets bytestream sent to
the terminal emulator to somehow cause arbitrary input bytes added
(which may require the final <ENTER> from the user but that is not
much of consolation), and I tend to agree with you on that point.

With that misfeature out of the picture, I am not sure why terminal
escape sequences that may clear or write-over things on the screen
are of particular interest.  If the malicious remote end says
something like

    To proceed, open another window and type this command:

	$ curl https://my.malicious.xz/install.sh | sh

to its output, even if the message is shown with the "remote: "
prefix on the receiving local client, wouldn't that cause certain
percentage of end-user population to copy-and-paste that command
anyway?

> I agree that this would have been a nice feature to add at the beginning
> of the development of the sideband feature, but I fear that it is too
> late to make an incompatible change now.

So I am not so sure even it would have been a "nice feature" to disallow
sideband messages to carry terminal escape sequences to begin with.

> I realize that you've provided an escape hatch, but as we've seen with
> other defense-in-depth measures, that doesn't avoid the inconvenience
> and hassle of dealing with those changes and the costs of deploying
> fixes everywhere.

One more thing that I am not so happy about these "escape hatches"
is that they tend to be all or nothing (not limited to this round,
but common to other defense-in-depth attempts).  Having to say "I
trust them completely" is something that would make people uneasy.

> We need to consider the costs and impact of these
> patches on our users, including the burden of dealing with incompatible
> changes, and given the fact that this problem can occur in a wide
> variety of other contexts which you are not solving here and which would
> be better solved more generally in terminal emulators themselves, I
> don't think the benefits of this approach outweigh the downsides.
>
> I do agree that there are terminal emulators which have some surprising
> and probably insecure behaviour, as we've discussed in the past, but
> because I believe those issues are more general and could be a problem
> for any terminal-using program, I continue to believe that those issues
> are best addressed in the terminal emulator itself.

Re: [PATCH 0/3] Sanitize sideband channel messages

[Ondrej Pohorelsky]

Hi,
I see that CVE-2024-52005 [0] has been assigned to this issue. From
the discussion, it seems the fix may not be shipped in the near
future, if at all.

Could you please confirm if I understand this correctly? Specifically,
that this is not being treated as a vulnerability and that the
proposed fix might introduce regressions for certain use cases?
We are bound by SLAs and need to decide soon whether to provide fixed
versions of Git in RHEL. Having clarity on the upstream stance would
be very helpful for our decision. Right now, we are inclined not to
ship these fixes unless they are accepted upstream.

[0] https://github.com/git/git/security/advisories/GHSA-7jjc-gg6m-3329


Best regards,
Ondřej Pohořelský


On Thu, Jan 16, 2025 at 7:47 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > Where pre-receive hooks are available, people frequently run various
> > commands to test and analyze code in them, including build or static
> > analysis tools, such as Rust's Cargo.  Cargo is capable of printing a
> > wide variety of escape sequences in its output, including `\e[K`, which
> > overwrites text to the right (e.g., for progress bars and status output
> > much like Git produces), and sequences for hyperlinks.  Stripping these
> > sequences would break the output in ways that would be confusing to the
> > user (since they work fine in a regular terminal) and hard to
> > reproduce or fix.
>
> You have ruled out the attack vector that lets bytestream sent to
> the terminal emulator to somehow cause arbitrary input bytes added
> (which may require the final <ENTER> from the user but that is not
> much of consolation), and I tend to agree with you on that point.
>
> With that misfeature out of the picture, I am not sure why terminal
> escape sequences that may clear or write-over things on the screen
> are of particular interest.  If the malicious remote end says
> something like
>
>     To proceed, open another window and type this command:
>
>         $ curl https://my.malicious.xz/install.sh | sh
>
> to its output, even if the message is shown with the "remote: "
> prefix on the receiving local client, wouldn't that cause certain
> percentage of end-user population to copy-and-paste that command
> anyway?
>
> > I agree that this would have been a nice feature to add at the beginning
> > of the development of the sideband feature, but I fear that it is too
> > late to make an incompatible change now.
>
> So I am not so sure even it would have been a "nice feature" to disallow
> sideband messages to carry terminal escape sequences to begin with.
>
> > I realize that you've provided an escape hatch, but as we've seen with
> > other defense-in-depth measures, that doesn't avoid the inconvenience
> > and hassle of dealing with those changes and the costs of deploying
> > fixes everywhere.
>
> One more thing that I am not so happy about these "escape hatches"
> is that they tend to be all or nothing (not limited to this round,
> but common to other defense-in-depth attempts).  Having to say "I
> trust them completely" is something that would make people uneasy.
>
> > We need to consider the costs and impact of these
> > patches on our users, including the burden of dealing with incompatible
> > changes, and given the fact that this problem can occur in a wide
> > variety of other contexts which you are not solving here and which would
> > be better solved more generally in terminal emulators themselves, I
> > don't think the benefits of this approach outweigh the downsides.
> >
> > I do agree that there are terminal emulators which have some surprising
> > and probably insecure behaviour, as we've discussed in the past, but
> > because I believe those issues are more general and could be a problem
> > for any terminal-using program, I continue to believe that those issues
> > are best addressed in the terminal emulator itself.
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat

opohorel@redhat.com

Re: [PATCH 0/3] Sanitize sideband channel messages

[Junio C Hamano]

Ondrej Pohorelsky <opohorel@redhat.com> writes:

> From
> the discussion, it seems the fix may not be shipped in the near
> future, if at all.

A patchset was sent, one person assessed that it is not solving the
right problem and introduces regressions, another person agreed.

It is not quite a discussion (yet) and I think there could be more
convincing argument for accepting regressions made, so I personally
feel that it is too early to call it settled yet, but without seeing
any further counter-arguments, I agree with you that things seem
that way.

Thanks.

Re: [PATCH 0/3] Sanitize sideband channel messages

[Johannes Schindelin]

Hi Junio,

On Wed, 15 Jan 2025, Junio C Hamano wrote:

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > Where pre-receive hooks are available, people frequently run various
> > commands to test and analyze code in them, including build or static
> > analysis tools, such as Rust's Cargo.  Cargo is capable of printing a
> > wide variety of escape sequences in its output, including `\e[K`, which
> > overwrites text to the right (e.g., for progress bars and status output
> > much like Git produces), and sequences for hyperlinks.  Stripping these
> > sequences would break the output in ways that would be confusing to the
> > user (since they work fine in a regular terminal) and hard to
> > reproduce or fix.
> 
> You have ruled out the attack vector that lets bytestream sent to
> the terminal emulator to somehow cause arbitrary input bytes added
> (which may require the final <ENTER> from the user but that is not
> much of consolation), and I tend to agree with you on that point.

So you haven't come across `OSC P 1 0 ; ? ST` (see e.g.
https://www.xfree86.org/current/ctlseqs.html#:~:text=OSC%20P%20s%20;%20P%20t%20ST
for this control sequence, as well as others that elicit responses from
terminal emulators, from current cursor position to terminal
capabilities)? I use this Escape sequence myself in my `tmux` sessions to
toggle the colors between bright-on-dark and dark-on-bright.

It is true that many terminal emulators started disabling support for such
Escape sequences. But that's not because the terminal emulators' features
were buggy. That's because some console programs are buggy, allowing
payload originating from outside the user's trust boundary to be passed
through to the terminal without proper sanitizing. That's what the entire
CWE-150 weakness class (https://cwe.mitre.org/data/definitions/150.html)
is all about.

And yes, it's the console programs that are buggy, not the terminal
emulators. It has always been the contract between terminal emulators and
software using those terminal emulators' features that the bytes that are
sent to the terminal emulator can do amazing stuff via control sequences
(that's the terminal emulators' promise) and the responsibility of the
software sending those bytes, in turn, is to make sure that it only sends
control characters intentionally and does not nilly-willy pass through
untrusted data from random outside sources.

That's the reason why even `tar` sanitizes its output, see
https://www.gnu.org/software/tar/manual/html_node/quoting-styles.html. Or
for that matter, cURL, see https://github.com/curl/curl/pull/1512 where
Escape sequences were part of the rationale.

While `mutt` might not sanitize the Escape sequences in the emails it
displays, it does something even better: It implements its own terminal
emulator that interprets only a very limited set of ANSI Escape sequences.
But since it uses ANSI Escape sequences to render the output, so in a very
convoluted way it _does_ sanitize Escape sequences.

Basically, all console programs interacting with terminal emulators are
careful about sanitizing untrusted payload before sending it to be
rendered.

In short, in this context it is clearly Git's responsibility to ensure
that control sequences do not originate from some stranger's server on the
internet and then are naively passed through to the terminal emulator
without the user's blessing. Git uses coloring sequences, after all, so it
benefits from the contract with the terminal emulator, and it must uphold
its end of the bargain, too.

Git also does an okay job of avoiding those color sequences when its
output does not even go to a terminal emulator, or when the `TERM`
environment variable indicates that the terminal emulator lacks
the prerequisite capabilities. (To do a better job, it would have to
query the terminal's capabilities, a job better left to libraries like
ncurses).

That check, whether the output is even sent to a terminal emulator or not,
is notably something that cannot ever be done by those `pre-receive` hooks
that were held up as examples to block this here patch series: They have
no way of knowing whether or not their output goes to a terminal, but they
send the control sequences anyway. Because YOLO, I guess. In that
respect, I think that even you two would agree that those `pre-receive`
hooks are broken by design.

> With that misfeature out of the picture, I am not sure why terminal
> escape sequences that may clear or write-over things on the screen
> are of particular interest.

It is important for attackers to try to hide any traces that might alert
their victims that they are being attacked. One fine way to do that is to
hide the output that would otherwise scream "You are under attack!" to the
user. Writing over such tell-tales, or erasing them altogether, is the
perfect tool for the job. As such, they are clearly of particular interest
in this context.

Sure, it is conceivable that there might be use cases where it _is_
desirable that certain text is first written and then overwritten by the
remote side. But the fact remains that it forcibly keeps open the door to
deceive the user into believing that they see something that they do not
actually see.

For example, Git goes out of its way to write out sideband messages only
with the `remote:` prefix. This is a very clear indicator that these
messages do not come from the local Git process, and users are very likely
to be extremely suspicious if they are prompted for some interactive input
in such a message. Allow the remote server to overwrite that prefix, and
you take away that indicator.

Besides, there are correct ways to send colored, or otherwise styled, text
to the user from the remote side: The remote side does not have the
ability to ask whether the output goes to a terminal, but the local Git
process does! The logic of color-coding the `error` and `warning` and
friends that was added in bf1a11f0a10 (sideband: highlight keywords in
remote sideband output, 2018-08-07) is a perfect example how this should
be done: The client side, the one with access to the terminal emulator,
decides what is permissible styling, and the remote side crafts its output
accordingly. No verbatim pass-through of control sequences, no
vulnerability, instant win. Well, not so instant, you first have to get
the patch on Git's side accepted, but that's par for the course.

Now, the capacities of modern terminal emulators are a far cry from what
they had been in the VT-100 times. As in: They have become drastically
more powerful. As illustrated at the beginning of my reply, there exist
powerful features to query information about the current terminal. Not all
of them are exploitable for malicious purposes on first sight. The crucial
part is: on first sight.

Also, it is relatively easy if you fail to protect your terminal emulator
to have your entire session messed up to a point where not even a `reset`
restores it. And corrupting the terminal session is still much better than
getting pranked by having all of Git's output be overwritten with a
picture of a snake (download the raw version of
https://github.com/csdvrx/sixel-testsuite/blob/master/snake.six -- after!
verifying that it is just a regular text file containing only a few
harmless escape sequences~ -- and then `cat` it to your terminal). That
could have been goatse, too, though. Or for that matter (as
https://github.com/mpv-player/mpv demonstrates, which allows you to render
entire Youtube videos in your current terminal window) you could be
Rick-rolled. And all of those are still pranks more than anything. Much
worse can be done with those terminal emulator capabilities.

> If the malicious remote end says something like
> 
>     To proceed, open another window and type this command:
> 
> 	$ curl https://my.malicious.xz/install.sh | sh
> 
> to its output, even if the message is shown with the "remote: "
> prefix on the receiving local client, wouldn't that cause certain
> percentage of end-user population to copy-and-paste that command
> anyway?

Sure, and there is no defending against users who voluntarily follow such
instructions without applying some healthy skepticism first. Not in Git,
anyways.

The kind of control illustrated above, however, can of course also be used
to pretend that _Git_ asks interactively for some input, using the exact
look&feel of Git's usual interactive prompts. And presented with something
like that, I would wager a bet that even you could fall for an elaborate
ruse, if I were a betting person. If I were still a student, with too much
time on my hands, I'd even try to prank you that way, purely for fun.

For the record, I was almost successfully gas-lit into believing that this
here issue is not even a vulnerability, as was claimed by some (but not
all) involved in the discussion on the Git security list. Fortunately I am
in a wonderful position that I have access to outstanding security
researchers, and I asked two of them, independently, to tell me whether or
not this is a vulnerability that needs to be fixed. Independently, both
agreed that my assessment "High" was too high, and it should have been
"Moderate" instead. At the same time, they also both agreed that it is a
vulnerability that should be fixed in Git.

I did hear that Google employs some excellent security professionals, too.
While I cannot ask them directly, I would be quite curious what they would
have to say about this issue. Maybe you could contact one or two?

Ciao,
Johannes

> 
> > I agree that this would have been a nice feature to add at the beginning
> > of the development of the sideband feature, but I fear that it is too
> > late to make an incompatible change now.
> 
> So I am not so sure even it would have been a "nice feature" to disallow
> sideband messages to carry terminal escape sequences to begin with.
> 
> > I realize that you've provided an escape hatch, but as we've seen with
> > other defense-in-depth measures, that doesn't avoid the inconvenience
> > and hassle of dealing with those changes and the costs of deploying
> > fixes everywhere.
> 
> One more thing that I am not so happy about these "escape hatches"
> is that they tend to be all or nothing (not limited to this round,
> but common to other defense-in-depth attempts).  Having to say "I
> trust them completely" is something that would make people uneasy.
> 
> > We need to consider the costs and impact of these
> > patches on our users, including the burden of dealing with incompatible
> > changes, and given the fact that this problem can occur in a wide
> > variety of other contexts which you are not solving here and which would
> > be better solved more generally in terminal emulators themselves, I
> > don't think the benefits of this approach outweigh the downsides.
> >
> > I do agree that there are terminal emulators which have some surprising
> > and probably insecure behaviour, as we've discussed in the past, but
> > because I believe those issues are more general and could be a problem
> > for any terminal-using program, I continue to believe that those issues
> > are best addressed in the terminal emulator itself.
> 
> 

Re: [PATCH 0/3] Sanitize sideband channel messages

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 16962 bytes --]

Hi Phillip,

On Wed, 15 Jan 2025, Phillip Wood wrote:

> On 14/01/2025 18:19, Johannes Schindelin via GitGitGadget wrote:
> > When a clone fails, users naturally turn to the output of the git
> > clone command. To assist in such scenarios, the output includes the messages
> > from the remote git pack-objects process, delivered via what Git calls the
> > "sideband channel."
> > 
> > Given that the remote server is, by nature, remote, there is no guarantee
> > that it runs an unmodified Git version. This exposes Git to ANSI escape
> > sequence injection (see
> > CWE-150, https://cwe.mitre.org/data/definitions/150.html), which can corrupt
> > terminal state, hide information,
> 
> I agree we should think about preventing an untrusted remote process from
> making it look like its messages come from the trusted local process. At best
> it is confusing and at worst it might trick a user into running a malicious
> command if they think the message came from the local git process.

It's actually much worse. With the right approach, you could trick a user
to think that they interact with Git, when in reality they are executing a
command instead.

> We need to be careful not to break existing legitimate output though.

Well, given that that "legitimate output" sends control sequences, whether
the output goes to a terminal window or to a pipe to be parsed by an
application, I don't think that it is _all_ that legitimate.

But then, I don't know why some people keep harping about this when the
patch series as-is already passes those color sequences through by
default?

> Brian has already highlighted the need to support '\e[K' (clear to the
> end of the current line), we may also want to treat '\e[G' (move to
> column 1 on the current line) as '\r' in addition to SGR escapes in the
> last patch.

Consider this: One of the most effective ways to fool a victim is to hide
suspicious information from them. In that respect, it is undesirable to
pass through those sequences that would allow just that.

Besides, color me surprised that this is even necessary? What use case
could there be to erase to the end of the line from a remote process, when
that process' output is supposed to be text that arrives word by word,
line by line, no backsies? What use case would be there to send a Carriage
Return other than to hide the `remote:` prefix?

I did play with the idea of optionally passing through those two
sequences, though, and came up with this patch (don't worry if it does not
apply on top of v1 of this here patch series, my local branch is currently
a bit in flux):

-- snip --
diff --git a/sideband.c b/sideband.c
index 0025b51b4e1..f613d4d6cc3 100644
--- a/sideband.c
+++ b/sideband.c
@@ -28,9 +28,42 @@ static struct keyword_entry keywords[] = {
 static enum {
 	ALLOW_NO_CONTROL_CHARACTERS = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
-	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+	ALLOW_ANSI_ERASE_IN_LINE = 1<<1,
+	ALLOW_ANSI_CURSOR_HORIZONTAL_ABSOLUTE = 1<<2,
+	ALLOW_DEFAULT_ANSI_SEQUENCES =
+		ALLOW_ANSI_COLOR_SEQUENCES |
+		ALLOW_ANSI_ERASE_IN_LINE |
+		ALLOW_ANSI_CURSOR_HORIZONTAL_ABSOLUTE,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
+} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+
+static inline int skip_prefix_in_csv(const char *value, const char *prefix,
+				     const char **out)
+{
+	if (!skip_prefix(value, prefix, &value) ||
+	    (*value && *value != ','))
+		return 0;
+	*out = value + !!*value;
+	return 1;
+}
+
+static void parse_allow_control_characters(const char *value)
+{
+	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+	while (*value) {
+		if (skip_prefix_in_csv(value, "default", &value))
+			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "color", &value))
+			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "erase-in-line", &value))
+			allow_control_characters |= ALLOW_ANSI_ERASE_IN_LINE;
+		else if (skip_prefix_in_csv(value, "cursor-horizontal-absolute", &value))
+			allow_control_characters |= ALLOW_ANSI_CURSOR_HORIZONTAL_ABSOLUTE;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+	}
+}
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -54,13 +87,8 @@ static int use_sideband_colors(void)
 		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
 					      &value))
 			; /* huh? `get_maybe_bool()` returned -1 */
-		else if (!strcmp(value, "default"))
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (!strcmp(value, "color"))
-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			parse_allow_control_characters(value);
 		break;
 	default:
 		break; /* not configured */
@@ -93,7 +121,7 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
@@ -107,12 +135,17 @@ static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
 	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
 	 */
 
-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+	if (n < 3 || src[0] != '\x1b' || src[1] != '[')
 		return 0;
 
+error("allow: 0x%x", allow_control_characters);
 	for (i = 2; i < n; i++) {
-		if (src[i] == 'm') {
+		if ((src[i] == 'G' &&
+		     (allow_control_characters & ALLOW_ANSI_CURSOR_HORIZONTAL_ABSOLUTE)) ||
+		    (src[i] == 'K' &&
+		     (allow_control_characters & ALLOW_ANSI_ERASE_IN_LINE)) ||
+		    (src[i] == 'm' &&
+		     (allow_control_characters & ALLOW_ANSI_COLOR_SEQUENCES))) {
 			strbuf_add(dest, src, i + 1);
 			return i;
 		}
@@ -127,7 +160,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
+	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -136,7 +169,8 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
 			strbuf_addch(dest, *src);
-		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+		else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
+			 (i = handle_ansi_sequence(dest, src, n))) {
 			src += i;
 			n -= i;
 		} else {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 98c575e2e7f..a59accd0ec2 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -104,7 +104,7 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
-	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
 
 	git clone --no-local . throw-away 2>stderr &&
@@ -129,4 +129,42 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_file_not_empty actual
 '
 
+test_decode_csi() {
+	awk '{
+		while (match($0, /\033/) != 0) {
+			printf "%sCSI ", substr($0, 1, RSTART-1);
+			$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
+		}
+		print
+	}'
+}
+
+test_expect_success 'control sequences in sideband allowed by default' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit-at-least &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep "CSI \\[G" decoded &&
+	test_grep "\\^\\[?25l" decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=erase-in-line,color \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "RED" decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep ! "CSI \\[G" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded &&
+	test_grep "\\^\\[\\[G" decoded
+'
+
 test_done
-- snap --

I am not particularly happy about the current shape of the patch because
the functionality it adds is not flexible enough. Currently I am thinking
about some sort of pattern matcher where users could configure
`sideband.allowControlCharacters="CSI [ K, CSI [ G"` or something. Or
`^[[K,^[[G`, i.e. reflecting the sanitized version of the control
sequences that should be passed through instead. But that might be totally
overengineered and not worth it.

After all, I have not received a single complaint about the new default in
Git for Windows, where only color sequences are passed through by default,
and all others are sanitized. which leads me to the very important
conclusion that the concerns that were raised, and that were considered
serious enough to prevent these patches to be included in the embargoed
release, were potentially far, far less concerning than originally
assumed.

Also: The suggestion on the git-security mailing list was to reach out for
input from the wider Git community to be able to come up with a better
solution than the small circle of developers on the git-security mailing
list could. Notwithstanding the fact that already the first reply to my
patch series sent a very strong message that at least one contributor
considered this already a closed case upon arrival, I have to point out
that apart from the ERASE-IN-LINE and CURSOR_HORIZONTAL_ABSOLUTE
suggestions, no other control sequences have been suggested as needing to
be passed through by default. And those suggestions came from someone who
had already been very vocal in the discussion on the git-security mailing
list, so maybe the suggestion to reach out to the wider commmunity was not
actually completely genuine interest in an improved patch series.

Besides, _iff_ there are users who need to enable control sequence
pass-through for anything else than color, they are likely to need that
only for a very small number of repositories, and for repositories whose
remote servers they trust, therefore they can easily just opt out of
sanitizing control sequences in those few repositories.

> > and even insert characters into the input buffer (as if the user had
> > typed those characters).
> 
> Maybe I've missed something but my understanding from the link above is that
> this is a non-issue for terminal emulators released in the last 20 years.

Oh, that's incorrect, at least if you talk about control sequences that
insert characters into the input buffer. Those control sequences which let
you query the terminal are used e.g. to determine the current window
dimensions. They very much insert characters into the input buffer. They
have to, there is no other way to return information back to the caller.

Maybe the _particular_ Escape sequence I talked about, to query the
foreground text color, has been quietly disabled in some terminal
emulators (but certainly not in all of them, I know, because I use that
feature in one of my terminal emulators all the time).

But I did caution already in the discussion on the git-security mailing
list against getting hung up with _one particular_ control sequence. Not
only does that forget about all the other wonderful control sequences used
for querying information from the terminal, they also completely neglect
that it is totally within terminal emulators' purview to introduce new
capabilities via new control sequences. Some people in this dicussion
would probably deem that stupid or terrible or something, or even that it
would render the terminal emulator _buggy_, but I'd argue that it's in the
same ballpark as introducing a new `git repo` command and breaking
everybody's setup who already had an `alias.repo`: It is _totally_ within
the remit of Git to introduce such a command _and_ break existing user's
setups that way. Just like it was within the Git project's rights to
rename all `.txt` files in `Documentation/`, breaking tons of existing
deeplinks on the web. Some people outside of the Git project rolled their
eyes about that decision, but they simply had no say in the matter. Same
goes for terminal emulators. The contract is clear: terminal emulators
interpret control sequences, software using them has to be careful what
control sequences it sends and has no vote which control sequences the
terminal emulator chooses to support or not.

Ciao,
Johannes

> In any case I think that that is a security bug in the emulator and
> should be fixed there as it has been in the past. I found [1] to be much
> more informative than the mitre link above about the actual
> vulnerabilities.
> 
> Best Wishes
> 
> Phillip
> 
> [1] https://marc.info/?l=bugtraq&m=104612710031920
> 
> > This patch series addresses this vulnerability by sanitizing the sideband
> > channel.
> > 
> > It is important to note that the lack of sanitization in the sideband
> > channel is already "exploited" by the Git user community, albeit in
> > well-intentioned ways. For instance, certain server-side hooks use ANSI
> > color sequences in error messages to make them more noticeable during
> > intentional failed fetches, e.g. as seen at
> > https://github.com/kikeonline/githook-explode and
> > https://github.com/arosien/bart/blob/HEAD/hooks/post-receive.php
> > 
> > To accommodate such use cases, Git will allow ANSI color sequences to pass
> > through by default, while presenting all other ASCII control characters in a
> > common form (e.g., presenting the ESC character as ^[).
> > 
> > This vulnerability was reported to the Git security mailing list in early
> > November, along with these fixes, as part of an iteration of the patches
> > that led to the coordinated security release on Tuesday, January 14th, 2025.
> > 
> > While Git for Windows included these fixes in v2.47.1(2), the consensus,
> > apart from one reviewer, was not to include them in Git's embargoed
> > versions. The risk was considered too high to disrupt existing scenarios
> > that depend on control characters received via the sideband channel being
> > sent verbatim to the user's terminal emulator.
> > 
> > Several reviewers suggested advising terminal emulator writers about these
> > "quality of implementation issues" instead. I was quite surprised by this
> > approach, as it seems overly optimistic to assume that terminal emulators
> > could distinguish between control characters intentionally sent by Git and
> > those unintentionally relayed from the remote server.
> > 
> > Please note that this patch series applies cleanly on top of v2.47.2. To
> > apply it cleanly on top of v2.40.4 (the oldest of the most recently serviced
> > security releases), the calls to test_grep need to be replaced with calls
> > to test_i18ngrep, and the calls to git_config_get_string_tmp() need to be
> > replaced with calls to git_config_get_string().
> > 
> > Johannes Schindelin (3):
> > sideband: mask control characters
> > sideband: introduce an "escape hatch" to allow control characters
> > sideband: do allow ANSI color sequences by default
> > 
> >   Documentation/config.txt            |  2 +
> >   Documentation/config/sideband.txt   | 16 ++++++
> >   sideband.c                          | 78 ++++++++++++++++++++++++++++-
> >   t/t5409-colorize-remote-messages.sh | 30 +++++++++++
> >   4 files changed, 124 insertions(+), 2 deletions(-)
> >   create mode 100644 Documentation/config/sideband.txt
> > 
> > 
> > base-commit: e1fbebe347426ef7974dc2198f8a277b7c31c8fe
> > Published-As:
> > https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git
> > pr-1853/dscho/sanitize-sideband-v1
> > Pull-Request: https://github.com/gitgitgadget/git/pull/1853
> 
> 

Re: [PATCH 1/3] sideband: mask control characters

[Johannes Schindelin]

Hi Phillip,

On Wed, 15 Jan 2025, Phillip Wood wrote:

> Just a couple of small comments
> 
> On 14/01/2025 18:19, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int
> > n)
> > +{
> > +	strbuf_grow(dest, n);
> > +	for (; n && *src; src++, n--) {
> > +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
> 
> Isn't it a bug to pass '\n' to maybe_colorize_sideband() ?

While a band 2 message is indeed split by newlines and fed to this
function line by line, which is the case for a long time already: since
ed1902ef5c6 (cope with multiple line breaks within sideband progress
messages, 2007-10-16), the same is not true for band 3 messages: They pass
the entire message in one go (and for multi-line payload, only the first
line is prefixed with `remote:`, which is arguably a bug, but not one that
is within this here patch series' scope).

See
https://gitlab.com/git-scm/git/-/blob/v2.52.0/sideband.c#L191 and
https://gitlab.com/git-scm/git/-/blob/v2.52.0/sideband.c#L176,
respectively.

So no, I don't think that we can currently consider it a bug to pass `\n`
as part of the `src` parameter to `maybe_colorize_sideband()`.

> > +			strbuf_addch(dest, *src);
> > +		else {
> > +			strbuf_addch(dest, '^');
> > +			strbuf_addch(dest, 0x40 + *src);
> 
> This will escape DEL ('\x7f') as "^\xbf" which is invalid in utf-8 locales.
> Perhaps we could use "^?" for that instead.

Good point! This seems to be the historical way to escape DEL, probably
because 0x3f ('?') is 0x7f + 0x40 truncated to 7 bits. I'll do this in the
next iteration:

-- snip --
diff --git a/sideband.c b/sideband.c
index f613d4d6cc3..684621579fd 100644
--- a/sideband.c
+++ b/sideband.c
@@ -175,7 +175,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 			n -= i;
 		} else {
 			strbuf_addch(dest, '^');
-			strbuf_addch(dest, 0x40 + *src);
+			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
 		}
 	}
 }
-- snap --

> 
> > +test_expect_success 'disallow (color) control sequences in sideband' '
> > +	write_script .git/color-me-surprised <<-\EOF &&
> > +	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
> > +	exec "$@"
> > +	EOF
> > +	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
> > +	test_commit need-at-least-one-commit &&
> > +	git clone --no-local . throw-away 2>stderr &&
> > +	test_decode_color <stderr >decoded &&
> > +	test_grep ! RED decoded
> 
> I'd be happier if we used test_cmp() here so that we check that the sanitized
> version matches what we expect and the test does not pass if there a typo in
> the script above stops it from writing the SGR code for red.

I often debug test failures in Git's test suite and one of the most
annoying category of test failures is when test cases expect byte-wise
exact Git output that changed for totally legitimate reasons [*1*].

Even worse: In many of those instances, the _intent_ of the check is not
even clear from that `test_cmp` and has to be reconstructed, a boring,
tedious task with little benefit to show for the effort.

I much prefer tests like this one, where a precise `test_grep` states
exactly what it expects to be present, or missing. The intent of such a
command is much clearer than that of `test_cmp expect actual`.

So, much as I appreciate your suggestion, I would prefer to keep the code
as-is.

Ciao,
Johannes

Footnote *1*: This really is not hypothetical. I had to battle quite a bit
with unstable compression sizes that are part of a `test_cmp` comparison,
https://github.com/git-for-windows/git/pull/5926#issuecomment-3486556940
shows a bit of the problems but is very shy about providing the specific
number of days I spent on addressing this issue. In hindsight, I should
have spent at most two hours on converting that from a byte-wise
comparison to a qualitative comparison.

Re: [PATCH 0/3] Sanitize sideband channel messages

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 7735 bytes --]

On 2025-12-02 at 14:11:54, Johannes Schindelin wrote:
> So you haven't come across `OSC P 1 0 ; ? ST` (see e.g.
> https://www.xfree86.org/current/ctlseqs.html#:~:text=OSC%20P%20s%20;%20P%20t%20ST
> for this control sequence, as well as others that elicit responses from
> terminal emulators, from current cursor position to terminal
> capabilities)? I use this Escape sequence myself in my `tmux` sessions to
> toggle the colors between bright-on-dark and dark-on-bright.

So let's talk about this class of escape sequences with your patches for
a moment.  I compiled the patches in this series on my system and
changed the default PATH to use that client-side git binary (the
server-side is unchanged).  I have not changed any configuration related
to your patches, so the behaviour is the patch default.

I have a server called castro (after the San Francisco neighbourhood)
and I added the following script called `~/bin/fake-git-upload-pack`,
which should let us simulate a malicious server:

----
#!/bin/sh

printf '\033]10;rgb:ffff/ffff/ffff\007Hello, world!\n' >&2

exec git-upload-pack "$@"
----

This basically uses this class of escape sequences to change the
foreground colour to bright white.

I then ran a clone command, like so:

----
% git clone -u fake-git-upload-pack castro:~/git/css.git
Cloning into 'css'...
Hello, world!
remote: Enumerating objects: 663, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 663 (delta 0), reused 0 (delta 0), pack-reused 659 (from 1)
Receiving objects: 100% (663/663), 114.83 KiB | 38.28 MiB/s, done.
Resolving deltas: 100% (329/329), done.
----

Despite my patched Git binary, the escape sequence was executed and my
foreground colour was changed.  So I don't think these patches are
sufficient to actually fix the issue and I somewhat doubt that it's even
possible at all to defend against a malicious SSH server which would
like to send arbitrary escape sequences in general.

I don't think we can just close stderr or not wire it up to the TTY
because OpenSSH needs the TTY to prompt and doing so also breaks things
on Windows.[0]  There are also cases where the remote side sends
messages over the Banner portion of the protocol that are required for
auth ($DAYJOB sends a unique URL for 2FA, for instance) and redirecting
stderr to `/dev/null` would mean that people couldn't log into those
machines.

If it's the case that we effectively can't fix this for SSH, I don't see
the advantage to trying to patch this for HTTPS, since it would give a
false sense of security and many people use both in their daily work (I
certainly do).

> It is true that many terminal emulators started disabling support for such
> Escape sequences. But that's not because the terminal emulators' features
> were buggy. That's because some console programs are buggy, allowing
> payload originating from outside the user's trust boundary to be passed
> through to the terminal without proper sanitizing. That's what the entire
> CWE-150 weakness class (https://cwe.mitre.org/data/definitions/150.html)
> is all about.

It is in general very difficult to eliminate all sources of untrusted
input in the terminal because people run `cat` and a variety of other
tools on untrusted files all the time.  It would certainly be convenient
if we did not need to deal with that case, but we do nonetheless.
That's why we've tended to patch terminal emulators when escape
sequences execute code.

> That check, whether the output is even sent to a terminal emulator or not,
> is notably something that cannot ever be done by those `pre-receive` hooks
> that were held up as examples to block this here patch series: They have
> no way of knowing whether or not their output goes to a terminal, but they
> send the control sequences anyway. Because YOLO, I guess. In that
> respect, I think that even you two would agree that those `pre-receive`
> hooks are broken by design.

I don't agree.  Lots of systems that are not terminals interpret
at least some terminal escape sequences, such as GitHub Actions.  And I
can tell you that there are a substantial number of organizations that do
indeed have actual pre-receive hooks in production that use terminal
escape sequences without actually knowing that the other side supports
them because I have had to troubleshoot those pre-receive hooks.

Even if we were to agree that it might not be desirable to send terminal
escape sequences without knowing if there's a terminal, people do it,
and even Vim does it (try `TERM=dumb vim -e`, whereupon it will send
escape sequences, much to my annoyance).  I don't think we can say that
everybody thinks this kind of thing is unreasonable and clearly some
people very much want to do it and make reasonably good use of it, so
it's a use case we should consider.

> Also, it is relatively easy if you fail to protect your terminal emulator
> to have your entire session messed up to a point where not even a `reset`
> restores it. And corrupting the terminal session is still much better than
> getting pranked by having all of Git's output be overwritten with a
> picture of a snake (download the raw version of
> https://github.com/csdvrx/sixel-testsuite/blob/master/snake.six -- after!
> verifying that it is just a regular text file containing only a few
> harmless escape sequences~ -- and then `cat` it to your terminal). That
> could have been goatse, too, though. Or for that matter (as
> https://github.com/mpv-player/mpv demonstrates, which allows you to render
> entire Youtube videos in your current terminal window) you could be
> Rick-rolled. And all of those are still pranks more than anything. Much
> worse can be done with those terminal emulator capabilities.

As I mentioned, sending Sixel images can be legitimately useful to send
things like QR codes to build outputs or for things like authentication.
Certainly there are less savoury things one can do as well.

> For the record, I was almost successfully gas-lit into believing that this
> here issue is not even a vulnerability, as was claimed by some (but not
> all) involved in the discussion on the Git security list. Fortunately I am
> in a wonderful position that I have access to outstanding security
> researchers, and I asked two of them, independently, to tell me whether or
> not this is a vulnerability that needs to be fixed. Independently, both
> agreed that my assessment "High" was too high, and it should have been
> "Moderate" instead. At the same time, they also both agreed that it is a
> vulnerability that should be fixed in Git.

I don't think "gas-lit" is an accurate characterization of the
discussion.  I disagreed with you that this was a Git-specific problem
and some others wanted more discussion about the matter.  I don't think
anyone else had intentions of misleading or deceiving you, or making you
doubt your memory or perceptions of reality, and I certainly did not.
Instead, we simply disagreed on a technical matter.  Linus and I have
clearly disagreed strongly on some matters on this list in the past and
I don't think that "gaslighting" would be an accurate characterization
there, either.

I will state that while I do disagree with you on this matter and it's
clear that we don't always see eye to eye or necessarily get along
famously, I do appreciate the work that you do for this project and Git
for Windows and I do respect you and your contributions.

[0] I remember this from Git LFS: https://github.com/git-lfs/git-lfs/issues/1843
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH 0/3] Sanitize sideband channel messages

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 13136 bytes --]

Hi brian,

On Wed, 3 Dec 2025, brian m. carlson wrote:

> On 2025-12-02 at 14:11:54, Johannes Schindelin wrote:
> > So you haven't come across `OSC P 1 0 ; ? ST` (see e.g.
> > https://www.xfree86.org/current/ctlseqs.html#:~:text=OSC%20P%20s%20;%20P%20t%20ST
> > for this control sequence, as well as others that elicit responses from
> > terminal emulators, from current cursor position to terminal
> > capabilities)? I use this Escape sequence myself in my `tmux` sessions to
> > toggle the colors between bright-on-dark and dark-on-bright.
> 
> So let's talk about this class of escape sequences with your patches for
> a moment.  I compiled the patches in this series on my system and
> changed the default PATH to use that client-side git binary (the
> server-side is unchanged).  I have not changed any configuration related
> to your patches, so the behaviour is the patch default.

Thank you for testing this patch series; I'm really happy that we can
cross this long-standing item off the list. It opens the door for us to
work together, and I am eager to keep the momentum going.

> I have a server called castro (after the San Francisco neighbourhood)
> and I added the following script called `~/bin/fake-git-upload-pack`,
> which should let us simulate a malicious server:
> 
> ----
> #!/bin/sh
> 
> printf '\033]10;rgb:ffff/ffff/ffff\007Hello, world!\n' >&2
> 
> exec git-upload-pack "$@"
> ----
> 
> This basically uses this class of escape sequences to change the
> foreground colour to bright white.
> 
> I then ran a clone command, like so:
> 
> ----
> % git clone -u fake-git-upload-pack castro:~/git/css.git
> Cloning into 'css'...
> Hello, world!
> remote: Enumerating objects: 663, done.
> remote: Counting objects: 100% (4/4), done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 663 (delta 0), reused 0 (delta 0), pack-reused 659 (from 1)
> Receiving objects: 100% (663/663), 114.83 KiB | 38.28 MiB/s, done.
> Resolving deltas: 100% (329/329), done.
> ----
> 
> Despite my patched Git binary, the escape sequence was executed and my
> foreground colour was changed.  So I don't think these patches are
> sufficient to actually fix the issue and I somewhat doubt that it's even
> possible at all to defend against a malicious SSH server which would
> like to send arbitrary escape sequences in general.
> 
> I don't think we can just close stderr or not wire it up to the TTY
> because OpenSSH needs the TTY to prompt and doing so also breaks things
> on Windows.[0]  There are also cases where the remote side sends
> messages over the Banner portion of the protocol that are required for
> auth ($DAYJOB sends a unique URL for 2FA, for instance) and redirecting
> stderr to `/dev/null` would mean that people couldn't log into those
> machines.

Just to clarify: the patches here are specifically about the sideband
behavior in HTTPS, where the attack scenario that I am trying to defend
against involves a malicious server posing as a trusted one, e.g. via a
domain that looks highly similar to "github.com". In that context, SSH
isn’t really applicable, victims would be immediately suspicious if asked
for SSH credentials.

So while your SSH tests are interesting, they’re outside the scope of this
patch series. If you’d like to explore equivalent fixes on the SSH side,
that would be a great complementary effort, but the focus here is ensuring
sideband over HTTPS is handled securely.

> If it's the case that we effectively can't fix this for SSH, I don't see
> the advantage to trying to patch this for HTTPS, since it would give a
> false sense of security and many people use both in their daily work (I
> certainly do).

Thanks for sharing your opinion.

I would frame it a bit differently, though: security is rarely
all‑or‑nothing, it’s a game of layers.

Even if SSH-based Git operations have weaknesses that seem to be unlikely
to be fully fixable right now, that doesn’t mean we should leave
HTTPS-based operations exposed when we can strengthen them. Each
improvement reduces the attack surface, and together they add up to
meaningful protection. So rather than a false sense of security, I see
this patch series as one necessary step in a layered approach. If
complementary work on SSH becomes possible, that would be great, but in
the meantime it seems rational to secure what we can.

> > It is true that many terminal emulators started disabling support for such
> > Escape sequences. But that's not because the terminal emulators' features
> > were buggy. That's because some console programs are buggy, allowing
> > payload originating from outside the user's trust boundary to be passed
> > through to the terminal without proper sanitizing. That's what the entire
> > CWE-150 weakness class (https://cwe.mitre.org/data/definitions/150.html)
> > is all about.
> 
> It is in general very difficult to eliminate all sources of untrusted
> input in the terminal because people run `cat` and a variety of other
> tools on untrusted files all the time.  It would certainly be convenient
> if we did not need to deal with that case, but we do nonetheless.
> That's why we've tended to patch terminal emulators when escape
> sequences execute code.

You’re right that users sometimes do things that are hard or impossible to
protect against. There is nothing we can do in Git's source code to
prevent a user from `cat`ing a malicous file, for example.

But what we _can_ do is to ensure that Git, at least, is as secure by
default as we can make it. In this context: to sanitize control sequences
originating from outside Git's (or the Git user's) control. That’s exactly
why CWE‑150 exists: the responsibility lies with programs to sanitize what
they pass through, rather than expecting terminal emulators to defend
against every possible misuse.

Patching terminal emulators is a last‑resort mitigation, and given the
number of terminal emulators, it's once again far from an "all-or-nothing"
situation. In line with your earlier argument, one terminal emulator's
maintainer could claim that _another_ terminal emulator is still
unpatched, so why should _they_ be required to patch theirs? You see where
that leads, to finger pointing instead of security, and we all lose. I'd
rather see all terminal emulator projects doing what is in their power to
add layers of security, just as I am trying to do what is in my power
regarding Git's security in this here mail thread.

Concretely, even if we cannot eliminate all sources of untrusted input in
the terminal, in general, we should at least do our best to prevent Git
from passing through untrusted input to the terminal.

> > That check, whether the output is even sent to a terminal emulator or not,
> > is notably something that cannot ever be done by those `pre-receive` hooks
> > that were held up as examples to block this here patch series: They have
> > no way of knowing whether or not their output goes to a terminal, but they
> > send the control sequences anyway. Because YOLO, I guess. In that
> > respect, I think that even you two would agree that those `pre-receive`
> > hooks are broken by design.
> 
> I don't agree.  Lots of systems that are not terminals interpret
> at least some terminal escape sequences, such as GitHub Actions.  And I
> can tell you that there are a substantial number of organizations that do
> indeed have actual pre-receive hooks in production that use terminal
> escape sequences without actually knowing that the other side supports
> them because I have had to troubleshoot those pre-receive hooks.

Oh, I can imagine how cumbersome troubleshooting such `pre-receive` hooks
can be. I can imagine how insistent the inventors of such hooks are on
doing a legitimate thing. And because they are paying customers... they
are right.

And far be I from noticing that many systems that are not terminals
interpret some Escape sequences. In the extensive research I conducted in
October and November last year in the course of developing this here patch
series, I even stumbled across successful exploits targeting users of
web-based log viewers that interpret such Escape sequences, a scenario in
which I myself would have easily fallen prey to such an attack, as I would
have been totally unprepared to even suspect that the log viewer shows me
anything but plain text.

Having said all that, it is incorrect in general to assume that all
consumers of the output of Git commands _can_ interpret Escape sequences,
even if there should be a surprising number of consumers that do.

> Even if we were to agree that it might not be desirable to send terminal
> escape sequences without knowing if there's a terminal, people do it,
> and even Vim does it (try `TERM=dumb vim -e`, whereupon it will send
> escape sequences, much to my annoyance).  I don't think we can say that
> everybody thinks this kind of thing is unreasonable and clearly some
> people very much want to do it and make reasonably good use of it, so
> it's a use case we should consider.

I am puzzled. Do you really want to maintain that it is rational to send
Escape sequences without checking whether the receiver can interpret them
as desired? By this rationale, we could simplify the logic in `color.c`
rather dramatically, and always send Escape sequences. If you think this
through, I am sure you will want to stop this train of thought.

> > Also, it is relatively easy if you fail to protect your terminal emulator
> > to have your entire session messed up to a point where not even a `reset`
> > restores it. And corrupting the terminal session is still much better than
> > getting pranked by having all of Git's output be overwritten with a
> > picture of a snake (download the raw version of
> > https://github.com/csdvrx/sixel-testsuite/blob/master/snake.six -- after!
> > verifying that it is just a regular text file containing only a few
> > harmless escape sequences~ -- and then `cat` it to your terminal). That
> > could have been goatse, too, though. Or for that matter (as
> > https://github.com/mpv-player/mpv demonstrates, which allows you to render
> > entire Youtube videos in your current terminal window) you could be
> > Rick-rolled. And all of those are still pranks more than anything. Much
> > worse can be done with those terminal emulator capabilities.
> 
> As I mentioned, sending Sixel images can be legitimately useful to send
> things like QR codes to build outputs or for things like authentication.
> Certainly there are less savoury things one can do as well.

Right. But the presence of legitimate use-cases does not legitimize
holding up bug fixes. For a humorous take on this, see https://xkcd.com/1172/.

By definition, every security bug fix is a breaking change. Just like the
user of the space bar heater in that xkcd comic, the `pre-receive` hooks
you cited rely on a bug that needs to be fixed.

And a bug in Git it is, it's a weakness, matching CWE-150, giving rise to
vulnerabilities I have illustrated on the git-security mailing list (which
I will make public once I am reasonably certain that most Git users have
had a chance to upgrade to versions that no longer have those
vulnerabilities).

Ciao,
Johannes

> > For the record, I was almost successfully gas-lit into believing that this
> > here issue is not even a vulnerability, as was claimed by some (but not
> > all) involved in the discussion on the Git security list. Fortunately I am
> > in a wonderful position that I have access to outstanding security
> > researchers, and I asked two of them, independently, to tell me whether or
> > not this is a vulnerability that needs to be fixed. Independently, both
> > agreed that my assessment "High" was too high, and it should have been
> > "Moderate" instead. At the same time, they also both agreed that it is a
> > vulnerability that should be fixed in Git.
> 
> I don't think "gas-lit" is an accurate characterization of the
> discussion.  I disagreed with you that this was a Git-specific problem
> and some others wanted more discussion about the matter.  I don't think
> anyone else had intentions of misleading or deceiving you, or making you
> doubt your memory or perceptions of reality, and I certainly did not.
> Instead, we simply disagreed on a technical matter.  Linus and I have
> clearly disagreed strongly on some matters on this list in the past and
> I don't think that "gaslighting" would be an accurate characterization
> there, either.
> 
> I will state that while I do disagree with you on this matter and it's
> clear that we don't always see eye to eye or necessarily get along
> famously, I do appreciate the work that you do for this project and Git
> for Windows and I do respect you and your contributions.
> 
> [0] I remember this from Git LFS: https://github.com/git-lfs/git-lfs/issues/1843
> -- 
> brian m. carlson (they/them)
> Toronto, Ontario, CA
> 

[PATCH v2 0/4] Sanitize sideband channel messages

[Johannes Schindelin via GitGitGadget]

Git's sideband channel passes server output directly to the client terminal
without sanitization. This includes progress messages, error output, and
diagnostics from remote hooks during clone, fetch, and push operations.

This creates an ANSI escape sequence injection vulnerability (CWE-150
[https://cwe.mitre.org/data/definitions/150.html]). A malicious or
compromised server can corrupt terminal state, obscure information, or
inject characters into the terminal's input buffer. The client has no
mechanism to distinguish between legitimate output and attack sequences.

This series fixes the vulnerability by sanitizing control characters in the
sideband output. ANSI color sequences (SGR codes) pass through by default,
since server-side hooks exist that use these for visibility (e.g.
https://github.com/kikeonline/githook-explode). By default, all other
control characters are rendered in caret notation (e.g., ESC becomes ^[).

Users who need different behavior get configuration options:
sideband.allowControlCharacters provides an escape hatch for environments
that require raw passthrough. The defaults are secure.

Note: This series applies cleanly on v2.47.3.

Changes since v1:

 * Applied the suggestions by Phillip and brian.
 * Rebased onto v2.47.3.
 * Added more categories of ANSI Escape sequences that can be enabled (but
   that are off by default because they could be used to hide information).

Johannes Schindelin (4):
  sideband: mask control characters
  sideband: introduce an "escape hatch" to allow control characters
  sideband: do allow ANSI color sequences by default
  sideband: add options to allow more control sequences to be passed
    through

 Documentation/config.txt            |   2 +
 Documentation/config/sideband.txt   |  24 +++++
 sideband.c                          | 148 +++++++++++++++++++++++++++-
 t/t5409-colorize-remote-messages.sh |  68 +++++++++++++
 4 files changed, 240 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/config/sideband.txt


base-commit: a52a24e03c8c711f1d5e252fba78f9276908129b
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1853/dscho/sanitize-sideband-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/1853

Range-diff vs v1:

 1:  f7fb7a3833 ! 1:  8d70476559 sideband: mask control characters
     @@ Commit message
          There is likely a need for more fine-grained controls instead of using a
          "heavy hammer" like this, which will be introduced subsequently.
      
     +    Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
       ## sideband.c ##
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
      +			strbuf_addch(dest, *src);
      +		else {
      +			strbuf_addch(dest, '^');
     -+			strbuf_addch(dest, 0x40 + *src);
     ++			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
      +		}
      +	}
      +}
     @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'fallback to color.ui'
      +	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
      +	exec "$@"
      +	EOF
     -+	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
     ++	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
      +	test_commit need-at-least-one-commit &&
      +	git clone --no-local . throw-away 2>stderr &&
      +	test_decode_color <stderr >decoded &&
 2:  14c612c69a ! 2:  2615abd8c5 sideband: introduce an "escape hatch" to allow control characters
     @@ Commit message
          To help with those use cases, give users a way to opt-out of the
          protections: `sideband.allowControlCharacters`.
      
     +    Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
       ## Documentation/config.txt ##
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
       ## t/t5409-colorize-remote-messages.sh ##
      @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' '
       	EOF
     - 	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
     + 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
       	test_commit need-at-least-one-commit &&
      +
       	git clone --no-local . throw-away 2>stderr &&
 3:  a26c4ed6ce ! 3:  44585ba1f4 sideband: do allow ANSI color sequences by default
     @@ Commit message
          to the terminal, and `sideband.allowControlCharacters` to override that
          behavior.
      
     -    However, some `pre-receive` hooks that are actively used in practice
     -    want to color their messages and therefore rely on the fact that Git
     -    passes them through to the terminal.
     +    However, as reported by brian m. carlson, some `pre-receive` hooks that
     +    are actively used in practice want to color their messages and therefore
     +    rely on the fact that Git passes them through to the terminal, even
     +    though they have no way to determine whether the receiving side can
     +    actually handle Escape sequences (think e.g. about the practice
     +    recommended by Git that third-party applications wishing to use Git
     +    functionality parse the output of Git commands).
      
          In contrast to other ANSI escape sequences, it is highly unlikely that
          coloring sequences can be essential tools in attack vectors that mislead
          Git users e.g. by hiding crucial information.
      
          Therefore we can have both: Continue to allow ANSI coloring sequences to
     -    be passed to the terminal, and neutralize all other ANSI escape
     -    sequences.
     +    be passed to the terminal by default, and neutralize all other ANSI
     +    Escape sequences.
      
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     @@ Documentation/config/sideband.txt
      +	this config setting to override this behavior:
      ++
      +--
     ++	default::
      +	color::
      +		Allow ANSI color sequences, line feeds and horizontal tabs,
      +		but mask all other control characters. This is the default.
     @@ sideband.c: static struct keyword_entry keywords[] = {
      -static int allow_control_characters;
      +static enum {
      +	ALLOW_NO_CONTROL_CHARACTERS = 0,
     -+	ALLOW_ALL_CONTROL_CHARACTERS = 1,
     -+	ALLOW_ANSI_COLOR_SEQUENCES = 2
     ++	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
     ++	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
     ++	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
      +} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
       
       /* Returns a color setting (GIT_COLOR_NEVER, etc). */
     @@ sideband.c: static int use_sideband_colors(void)
      +		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
      +					      &value))
      +			; /* huh? `get_maybe_bool()` returned -1 */
     ++		else if (!strcmp(value, "default"))
     ++			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
      +		else if (!strcmp(value, "color"))
      +			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
      +		else
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
      +	 * Valid ANSI color sequences are of the form
      +	 *
      +	 * ESC [ [<n> [; <n>]*] m
     ++	 *
     ++	 * These are part of the Select Graphic Rendition sequences which
     ++	 * contain more than just color sequences, for more details see
     ++	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
      +	 */
      +
      +	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
     @@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *sr
      +			n -= i;
      +		} else {
       			strbuf_addch(dest, '^');
     - 			strbuf_addch(dest, 0x40 + *src);
     + 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
       		}
      
       ## t/t5409-colorize-remote-messages.sh ##
     @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'fallback to color.ui'
      +	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
       	exec "$@"
       	EOF
     - 	test_config_global uploadPack.packObjectshook ./color-me-surprised &&
     + 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
      @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' '
       
       	git clone --no-local . throw-away 2>stderr &&
 -:  ---------- > 4:  fe109cd331 sideband: add options to allow more control sequences to be passed through

-- 
gitgitgadget

[PATCH v2 1/4] sideband: mask control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The output of `git clone` is a vital component for understanding what
has happened when things go wrong. However, these logs are partially
under the control of the remote server (via the "sideband", which
typically contains what the remote `git pack-objects` process sends to
`stderr`), and is currently not sanitized by Git.

This makes Git susceptible to ANSI escape sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
attackers to corrupt terminal state, to hide information, and even to
insert characters into the input buffer (i.e. as if the user had typed
those characters).

To plug this vulnerability, disallow any control character in the
sideband, replacing them instead with the common `^<letter/symbol>`
(e.g. `^[` for `\x1b`, `^A` for `\x01`).

There is likely a need for more fine-grained controls instead of using a
"heavy hammer" like this, which will be introduced subsequently.

Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 sideband.c                          | 17 +++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 12 ++++++++++++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/sideband.c b/sideband.c
index 02805573fa..fc1805dcf8 100644
--- a/sideband.c
+++ b/sideband.c
@@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
+{
+	strbuf_grow(dest, n);
+	for (; n && *src; src++, n--) {
+		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
+			strbuf_addch(dest, *src);
+		else {
+			strbuf_addch(dest, '^');
+			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
+		}
+	}
+}
+
 /*
  * Optionally highlight one keyword in remote output if it appears at the start
  * of the line. This should be called for a single line only, which is
@@ -80,7 +93,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 	int i;
 
 	if (!want_color_stderr(use_sideband_colors())) {
-		strbuf_add(dest, src, n);
+		strbuf_add_sanitized(dest, src, n);
 		return;
 	}
 
@@ -113,7 +126,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 		}
 	}
 
-	strbuf_add(dest, src, n);
+	strbuf_add_sanitized(dest, src, n);
 }
 
 
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 516b22fd96..f4712f4161 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -99,4 +99,16 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+test_expect_success 'disallow (color) control sequences in sideband' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep ! RED decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding commit fixed the vulnerability whereas sideband messages
(that are under the control of the remote server) could contain ANSI
escape sequences that would be sent to the terminal verbatim.

However, this fix may not be desirable under all circumstances, e.g.
when remote servers deliberately add coloring to their messages to
increase their urgency.

To help with those use cases, give users a way to opt-out of the
protections: `sideband.allowControlCharacters`.

Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config.txt            |  2 ++
 Documentation/config/sideband.txt   |  5 +++++
 sideband.c                          | 10 ++++++++++
 t/t5409-colorize-remote-messages.sh |  8 +++++++-
 4 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/config/sideband.txt

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8c0b3ed807..48870bb588 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -522,6 +522,8 @@ include::config/sequencer.txt[]
 
 include::config/showbranch.txt[]
 
+include::config/sideband.txt[]
+
 include::config/sparse.txt[]
 
 include::config/splitindex.txt[]
diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
new file mode 100644
index 0000000000..3fb5045cd7
--- /dev/null
+++ b/Documentation/config/sideband.txt
@@ -0,0 +1,5 @@
+sideband.allowControlCharacters::
+	By default, control characters that are delivered via the sideband
+	are masked, to prevent potentially unwanted ANSI escape sequences
+	from being sent to the terminal. Use this config setting to override
+	this behavior.
diff --git a/sideband.c b/sideband.c
index fc1805dcf8..997430f2ea 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,6 +25,8 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
+static int allow_control_characters;
+
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
 {
@@ -38,6 +40,9 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
+	git_config_get_bool("sideband.allowcontrolcharacters",
+			    &allow_control_characters);
+
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
 	else if (!git_config_get_string_tmp("color.ui", &value))
@@ -67,6 +72,11 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
+	if (allow_control_characters) {
+		strbuf_add(dest, src, n);
+		return;
+	}
+
 	strbuf_grow(dest, n);
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index f4712f4161..e8067df591 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -106,9 +106,15 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
+
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep ! RED decoded
+	test_grep ! RED decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep RED decoded
 '
 
 test_done
-- 
gitgitgadget

[PATCH v2 3/4] sideband: do allow ANSI color sequences by default

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding two commits introduced special handling of the sideband
channel to neutralize ANSI escape sequences before sending the payload
to the terminal, and `sideband.allowControlCharacters` to override that
behavior.

However, as reported by brian m. carlson, some `pre-receive` hooks that
are actively used in practice want to color their messages and therefore
rely on the fact that Git passes them through to the terminal, even
though they have no way to determine whether the receiving side can
actually handle Escape sequences (think e.g. about the practice
recommended by Git that third-party applications wishing to use Git
functionality parse the output of Git commands).

In contrast to other ANSI escape sequences, it is highly unlikely that
coloring sequences can be essential tools in attack vectors that mislead
Git users e.g. by hiding crucial information.

Therefore we can have both: Continue to allow ANSI coloring sequences to
be passed to the terminal by default, and neutralize all other ANSI
Escape sequences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   | 18 ++++++--
 sideband.c                          | 68 ++++++++++++++++++++++++++---
 t/t5409-colorize-remote-messages.sh | 16 ++++++-
 3 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 3fb5045cd7..e5b7383c7a 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -1,5 +1,17 @@
 sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
-	are masked, to prevent potentially unwanted ANSI escape sequences
-	from being sent to the terminal. Use this config setting to override
-	this behavior.
+	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal. Use
+	this config setting to override this behavior:
++
+--
+	default::
+	color::
+		Allow ANSI color sequences, line feeds and horizontal tabs,
+		but mask all other control characters. This is the default.
+	false::
+		Mask all control characters other than line feeds and
+		horizontal tabs.
+	true::
+		Allow all control characters to be sent to the terminal.
+--
diff --git a/sideband.c b/sideband.c
index 997430f2ea..fb43008ab7 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,7 +25,12 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
-static int allow_control_characters;
+static enum {
+	ALLOW_NO_CONTROL_CHARACTERS = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
+	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
+} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -40,8 +45,26 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	git_config_get_bool("sideband.allowcontrolcharacters",
-			    &allow_control_characters);
+	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
+	case 0: /* Boolean value */
+		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
+			ALLOW_NO_CONTROL_CHARACTERS;
+		break;
+	case -1: /* non-Boolean value */
+		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
+					      &value))
+			; /* huh? `get_maybe_bool()` returned -1 */
+		else if (!strcmp(value, "default"))
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (!strcmp(value, "color"))
+			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+		break;
+	default:
+		break; /* not configured */
+	}
 
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
@@ -70,9 +93,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+{
+	int i;
+
+	/*
+	 * Valid ANSI color sequences are of the form
+	 *
+	 * ESC [ [<n> [; <n>]*] m
+	 *
+	 * These are part of the Select Graphic Rendition sequences which
+	 * contain more than just color sequences, for more details see
+	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 */
+
+	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
+	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+		return 0;
+
+	for (i = 2; i < n; i++) {
+		if (src[i] == 'm') {
+			strbuf_add(dest, src, i + 1);
+			return i;
+		}
+		if (!isdigit(src[i]) && src[i] != ';')
+			break;
+	}
+
+	return 0;
+}
+
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
-	if (allow_control_characters) {
+	int i;
+
+	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -81,7 +136,10 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
 			strbuf_addch(dest, *src);
-		else {
+		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+			src += i;
+			n -= i;
+		} else {
 			strbuf_addch(dest, '^');
 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
 		}
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index e8067df591..f34977b332 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -101,7 +101,7 @@ test_expect_success 'fallback to color.ui' '
 
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
-	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
@@ -109,12 +109,24 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
+	test_grep RED decoded &&
+	test_grep "\\^G" stderr &&
+	tr -dc "\\007" <stderr >actual &&
+	test_must_be_empty actual &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=false \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
 	test_grep ! RED decoded &&
+	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
 	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep RED decoded
+	test_grep RED decoded &&
+	tr -dc "\\007" <stderr >actual &&
+	test_file_not_empty actual
 '
 
 test_done
-- 
gitgitgadget

[PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Even though control sequences that erase characters are quite juicy for
attack scenarios, where attackers are eager to hide traces of suspicious
activities, during the review of the side band sanitizing patch series
concerns were raised that there might be some legimitate scenarios where
Git server's `pre-receive` hooks use those sequences in a benign way.

Control sequences to move the cursor can likewise be used to hide tracks
by overwriting characters, and have been equally pointed out as having
legitimate users.

Let's add options to let users opt into passing through those ANSI
Escape sequences: `sideband.allowControlCharacters` now supports also
`cursor` and `erase`, and it parses the value as a comma-separated list.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   |  9 ++-
 sideband.c                          | 91 ++++++++++++++++++++++++-----
 t/t5409-colorize-remote-messages.sh | 38 ++++++++++++
 3 files changed, 123 insertions(+), 15 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index e5b7383c7a..8eb7656cdd 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -2,13 +2,20 @@ sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
 	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior:
+	this config setting to override this behavior (the value can be
+	a comma-separated list of the following keywords):
 +
 --
 	default::
 	color::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
+	cursor::
+		Allow control sequences that move the cursor. This is
+		disabled by default.
+	erase::
+		Allow control sequences that erase charactrs. This is
+		disabled by default.
 	false::
 		Mask all control characters other than line feeds and
 		horizontal tabs.
diff --git a/sideband.c b/sideband.c
index fb43008ab7..725e24db0d 100644
--- a/sideband.c
+++ b/sideband.c
@@ -28,9 +28,43 @@ static struct keyword_entry keywords[] = {
 static enum {
 	ALLOW_NO_CONTROL_CHARACTERS = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
+	ALLOW_ANSI_ERASE = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
+} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+
+static inline int skip_prefix_in_csv(const char *value, const char *prefix,
+				     const char **out)
+{
+	if (!skip_prefix(value, prefix, &value) ||
+	    (*value && *value != ','))
+		return 0;
+	*out = value + !!*value;
+	return 1;
+}
+
+static void parse_allow_control_characters(const char *value)
+{
+	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+	while (*value) {
+		if (skip_prefix_in_csv(value, "default", &value))
+			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "color", &value))
+			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "cursor", &value))
+			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
+		else if (skip_prefix_in_csv(value, "erase", &value))
+			allow_control_characters |= ALLOW_ANSI_ERASE;
+		else if (skip_prefix_in_csv(value, "true", &value))
+			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		else if (skip_prefix_in_csv(value, "false", &value))
+			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+	}
+}
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -54,13 +88,8 @@ static int use_sideband_colors(void)
 		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
 					      &value))
 			; /* huh? `get_maybe_bool()` returned -1 */
-		else if (!strcmp(value, "default"))
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (!strcmp(value, "color"))
-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			parse_allow_control_characters(value);
 		break;
 	default:
 		break; /* not configured */
@@ -93,7 +122,7 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
@@ -105,14 +134,47 @@ static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
 	 * These are part of the Select Graphic Rendition sequences which
 	 * contain more than just color sequences, for more details see
 	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 *
+	 * The cursor movement sequences are:
+	 *
+	 * ESC [ n A - Cursor up n lines (CUU)
+	 * ESC [ n B - Cursor down n lines (CUD)
+	 * ESC [ n C - Cursor forward n columns (CUF)
+	 * ESC [ n D - Cursor back n columns (CUB)
+	 * ESC [ n E - Cursor next line, beginning (CNL)
+	 * ESC [ n F - Cursor previous line, beginning (CPL)
+	 * ESC [ n G - Cursor to column n (CHA)
+	 * ESC [ n ; m H - Cursor position (row n, col m) (CUP)
+	 * ESC [ n ; m f - Same as H (HVP)
+	 *
+	 * The sequences to erase characters are:
+	 *
+	 *
+	 * ESC [ 0 J - Clear from cursor to end of screen (ED)
+	 * ESC [ 1 J - Clear from cursor to beginning of screen (ED)
+	 * ESC [ 2 J - Clear entire screen (ED)
+	 * ESC [ 3 J - Clear entire screen + scrollback (ED) - xterm extension
+	 * ESC [ 0 K - Clear from cursor to end of line (EL)
+	 * ESC [ 1 K - Clear from cursor to beginning of line (EL)
+	 * ESC [ 2 K - Clear entire line (EL)
+	 * ESC [ n M - Delete n lines (DL)
+	 * ESC [ n P - Delete n characters (DCH)
+	 * ESC [ n X - Erase n characters (ECH)
+	 *
+	 * For a comprehensive list of common ANSI Escape sequences, see
+	 * https://www.xfree86.org/current/ctlseqs.html
 	 */
 
-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+	if (n < 3 || src[0] != '\x1b' || src[1] != '[')
 		return 0;
 
 	for (i = 2; i < n; i++) {
-		if (src[i] == 'm') {
+		if (((allow_control_characters & ALLOW_ANSI_COLOR_SEQUENCES) &&
+		     src[i] == 'm') ||
+		    ((allow_control_characters & ALLOW_ANSI_CURSOR_MOVEMENTS) &&
+		     strchr("ABCDEFGHf", src[i])) ||
+		    ((allow_control_characters & ALLOW_ANSI_ERASE) &&
+		     strchr("JKMPX", src[i]))) {
 			strbuf_add(dest, src, i + 1);
 			return i;
 		}
@@ -127,7 +189,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
+	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -136,7 +198,8 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
 			strbuf_addch(dest, *src);
-		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+		else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
+			 (i = handle_ansi_sequence(dest, src, n))) {
 			src += i;
 			n -= i;
 		} else {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index f34977b332..c3e4e14362 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -129,4 +129,42 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_file_not_empty actual
 '
 
+test_decode_csi() {
+	awk '{
+		while (match($0, /\033/) != 0) {
+			printf "%sCSI ", substr($0, 1, RSTART-1);
+			$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
+		}
+		print
+	}'
+}
+
+test_expect_success 'control sequences in sideband allowed by default' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit-at-least &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep ! "CSI \\[G" decoded &&
+	test_grep "\\^\\[?25l" decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=erase,cursor,color \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "RED" decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep "CSI \\[G" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded &&
+	test_grep ! "\\^\\[\\[G" decoded
+'
+
 test_done
-- 
gitgitgadget

Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Junio C Hamano]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
> new file mode 100644
> index 0000000000..3fb5045cd7
> --- /dev/null
> +++ b/Documentation/config/sideband.txt
> @@ -0,0 +1,5 @@
> +sideband.allowControlCharacters::
> +	By default, control characters that are delivered via the sideband
> +	are masked, to prevent potentially unwanted ANSI escape sequences
> +	from being sent to the terminal. Use this config setting to override
> +	this behavior.

Two thoughts.

 - Users may want to say "I trust this remote host" or "I trust this
   remote repository".  For that, something similar to what we do to
   `http.variable` to allow `http.<url>.variable` to take precedence
   over `http.variable` would be necessary.

 - It may no longer matter but a remote repository that may send
   messages as strings encoded in ISO/IEC 2022 would need to set
   this, merely to make the messages human-readable.  There may be
   other reasons the trusted repositories want to send "escape
   sequences".

It might even be a good idea to make the default setting of this
variable "allow", except for the initial connections to repositories
(i.e., "git clone $URL", and "git fetch/ls-remote $URL" with an
explicit $URL without using a nickname recorded in our .git/config),
as visiting a potentially malicious remote repository you are not
familiar with may not be uncommon, and users may deserve protection
over inconvenience.

But once the user establishes a working relationship with a remote
repository, would it be a lot more common to trust the contents
there than be on the lookout that the repository may spew bad
strings of bytes at your standard error stream, I have to wonder.

Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin]

Hi Junio,

On Thu, 18 Dec 2025, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
> 
> > diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
> > new file mode 100644
> > index 0000000000..3fb5045cd7
> > --- /dev/null
> > +++ b/Documentation/config/sideband.txt
> > @@ -0,0 +1,5 @@
> > +sideband.allowControlCharacters::
> > +	By default, control characters that are delivered via the sideband
> > +	are masked, to prevent potentially unwanted ANSI escape sequences
> > +	from being sent to the terminal. Use this config setting to override
> > +	this behavior.
> 
> Two thoughts.
> 
>  - Users may want to say "I trust this remote host" or "I trust this
>    remote repository".  For that, something similar to what we do to
>    `http.variable` to allow `http.<url>.variable` to take precedence
>    over `http.variable` would be necessary.

Good idea! What do you think about something like this?

-- snip --
diff --git a/http.c b/http.c
index d59e59f66b1..14b5a95586c 100644
--- a/http.c
+++ b/http.c
@@ -19,6 +19,7 @@
 #include "string-list.h"
 #include "object-file.h"
 #include "object-store-ll.h"
+#include "sideband.h"
 
 static struct trace_key trace_curl = TRACE_KEY_INIT(CURL);
 static int trace_curl_data = 1;
@@ -566,6 +567,9 @@ static int http_options(const char *var, const char *value,
 		return 0;
 	}
 
+	if (!strcmp("http.sanitizesideband", var))
+		return sideband_allow_control_characters_config(var, value);
+
 	/* Fall back on the default ones */
 	return git_default_config(var, value, ctx, data);
 }
diff --git a/sideband.c b/sideband.c
index 725e24db0db..178c1320cac 100644
--- a/sideband.c
+++ b/sideband.c
@@ -26,13 +26,14 @@ static struct keyword_entry keywords[] = {
 };
 
 static enum {
+	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
 	ALLOW_NO_CONTROL_CHARACTERS = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
 	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
 	ALLOW_ANSI_ERASE = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
 	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
-} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+} allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 				     const char **out)
@@ -44,8 +45,19 @@ static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 	return 1;
 }
 
-static void parse_allow_control_characters(const char *value)
+int sideband_allow_control_characters_config(const char *var, const char *value)
 {
+	switch (git_parse_maybe_bool(value)) {
+	case 0:
+		allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		return 0;
+	case 1:
+		allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		return 0;
+	default:
+		break;
+	}
+
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
 		if (skip_prefix_in_csv(value, "default", &value))
@@ -61,9 +73,9 @@ static void parse_allow_control_characters(const char *value)
 		else if (skip_prefix_in_csv(value, "false", &value))
 			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			warning(_("unrecognized value for '%s': '%s'"), var, value);
 	}
+	return 0;
 }
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
@@ -79,20 +91,12 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
-	case 0: /* Boolean value */
-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
-			ALLOW_NO_CONTROL_CHARACTERS;
-		break;
-	case -1: /* non-Boolean value */
-		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
-					      &value))
-			; /* huh? `get_maybe_bool()` returned -1 */
-		else
-			parse_allow_control_characters(value);
-		break;
-	default:
-		break; /* not configured */
+	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
+		if (!git_config_get_value("sideband.allowcontrolcharacters", &value))
+			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
+
+		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
 	}
 
 	if (!git_config_get_string_tmp(key, &value))
diff --git a/sideband.h b/sideband.h
index 5a25331be55..e711ad0f4e0 100644
--- a/sideband.h
+++ b/sideband.h
@@ -30,4 +30,11 @@ int demultiplex_sideband(const char *me, int status,
 
 void send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
 
+/*
+ * Parse and set the sideband allow control characters configuration.
+ * The var parameter should be the key name (without section prefix).
+ * Returns 0 if the variable was recognized and handled, non-zero otherwise.
+ */
+int sideband_allow_control_characters_config(const char *var, const char *value);
+
 #endif
-- snap --

If this is the direction you're thinking, I'll polish it and integrate it
into v3.

>  - It may no longer matter but a remote repository that may send
>    messages as strings encoded in ISO/IEC 2022 would need to set
>    this, merely to make the messages human-readable.  There may be
>    other reasons the trusted repositories want to send "escape
>    sequences".

If the remote side has no way to determine whether the client side is
connected to a terminal or not (which we have already established in this
thread), it has even less chance to determine which character encoding is
in use...

> It might even be a good idea to make the default setting of this
> variable "allow", except for the initial connections to repositories
> (i.e., "git clone $URL", and "git fetch/ls-remote $URL" with an
> explicit $URL without using a nickname recorded in our .git/config),
> as visiting a potentially malicious remote repository you are not
> familiar with may not be uncommon, and users may deserve protection
> over inconvenience.
> 
> But once the user establishes a working relationship with a remote
> repository, would it be a lot more common to trust the contents
> there than be on the lookout that the repository may spew bad
> strings of bytes at your standard error stream, I have to wonder.

I am not so sure whether that would be desirable, for (at least :-) ) two
reasons:

- `git fetch` with an explicit URL is sometimes used outside clone
  scenarios, and in some clone-type scenarios, `git clone` cannot be used
  (e.g. to establish credentials or to determine the appropriate sparse
  checkout based on information from the tip revision).

  I know that it is a delicate balance to strike between convenience and
  security. Yet I also know that users prefer easy-to-explain mental
  models and this logic would be a bit hard to explain: Why disallow
  something while cloning or fetching with an explicit URL while allowing
  the very same thing in a subsequent fetch?

  tl;dr I expect users to be much more okay with the strategy to disallow
  all but very few ANSI sequences by default, with a message that tells
  them what to do if they want to enable more (or all) control sequences.

- I do not see how the user can inspect what the remote side does, even
  after an initial clone. Therefore users would not have any reasonable
  chance to gain any confidence that the remote side isn't doing anything
  malicious. To the contrary, remote servers could specifically "behave"
  during a clone, and launch the attack only during a fetch (indicated by
  "have" lines in the request).

  tl;dr remote servers don't get more trustworthy just by successfully
  serving clones.

Does that reasoning make sense to you?

Ciao,
Johannes

Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Good idea! What do you think about something like this?

It may be easier to hack up to piggyback on the http.*.variable
infrastructure, but I do not like the smell of it very much, because
the implementation ties it too tightly to the http transport; I
think this should live in one layer up (transport?).

> If this is the direction you're thinking, I'll polish it and integrate it
> into v3.

In other words, it would be more like sideband.allowEscapeSequences
that is overridden by sideband.<url>.allowEscapeSequences was what I
had in mind.  Or even transfer.allowEscapeSequencesInSideband that
is overridden by transfer.<url>.allowEscapeSequencesInSideband.

>>  - It may no longer matter but a remote repository that may send
>>    messages as strings encoded in ISO/IEC 2022 would need to set
>>    this, merely to make the messages human-readable.  There may be
>>    other reasons the trusted repositories want to send "escape
>>    sequences".
>
> If the remote side has no way to determine whether the client side is
> connected to a terminal or not (which we have already established in this
> thread), it has even less chance to determine which character encoding is
> in use...

Then I think you need to re-read brian's

  https://lore.kernel.org/git/aS-D5lD2Kk6BHNIl@fruit.crustytoothpaste.net/

In any case, I do not think ISO/IEC 2022 matters as much as it used
to back when the reencode_string_iconv() was written (which was the
topic of another thread regarding the broken iconv on macOS wrt
2022).  But even if we limit ourselves to UTF-8, brian's point that
applications do assume certain characteristics on its clients and
implements unportable stuff.  A project targetting developers and/or
users from certain locale may use their own hooks that assumes the
clients understands strings in certain language in certain encoding.

And to serve these projects better, classes like "pass colors",
"pass cursor movements", might help than just "pass everything" vs
"deny everything", but we probably want to try to keep it as simple
as possible; trying to make it finer grained with extra complexity
would only make our efforts look like whack-a-mole X-<.

>> It might even be a good idea to make the default setting of this
>> variable "allow", except for the initial connections to repositories
>> (i.e., "git clone $URL", and "git fetch/ls-remote $URL" with an
>> explicit $URL without using a nickname recorded in our .git/config),
>> as visiting a potentially malicious remote repository you are not
>> familiar with may not be uncommon, and users may deserve protection
>> over inconvenience.
>> 
>> But once the user establishes a working relationship with a remote
>> repository, would it be a lot more common to trust the contents
>> there than be on the lookout that the repository may spew bad
>> strings of bytes at your standard error stream, I have to wonder.

>   tl;dr remote servers don't get more trustworthy just by successfully
>   serving clones.

The "successfully serving clone" has nothing to do with the reason
why I suggested to deny by default in "clone" and anything that gets
$URL not remote nickname.  I am roughly equating the fact that the
user cloned *and* *then* continues to interact with the project that
is served from that remote repository (hence using the remote
nickname) with the willingness by the user to trust that particular
remote repository.

Re: [PATCH v2 1/4] sideband: mask control characters

[Patrick Steinhardt]

On Wed, Dec 17, 2025 at 02:23:39PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The output of `git clone` is a vital component for understanding what
> has happened when things go wrong. However, these logs are partially
> under the control of the remote server (via the "sideband", which
> typically contains what the remote `git pack-objects` process sends to
> `stderr`), and is currently not sanitized by Git.
> 
> This makes Git susceptible to ANSI escape sequence injection (see
> CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
> attackers to corrupt terminal state, to hide information, and even to
> insert characters into the input buffer (i.e. as if the user had typed
> those characters).
> 
> To plug this vulnerability, disallow any control character in the
> sideband, replacing them instead with the common `^<letter/symbol>`
> (e.g. `^[` for `\x1b`, `^A` for `\x01`).
> 
> There is likely a need for more fine-grained controls instead of using a
> "heavy hammer" like this, which will be introduced subsequently.

Most notably color codes, I assume.

> diff --git a/sideband.c b/sideband.c
> index 02805573fa..fc1805dcf8 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
>  		list_config_item(list, prefix, keywords[i].keyword);
>  }
>  
> +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)

Shouldn't `n` be of type `size_t`? I guess the answer is "maybe", as
`maybe_colorize_sideband()` also accepts `int n` with a big comment
explaining why that's okay. Ultimately, the reason is that we accept
pkt-lines, so every line is limited to at most 64kB anyway.

> +{
> +	strbuf_grow(dest, n);
> +	for (; n && *src; src++, n--) {
> +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
> +			strbuf_addch(dest, *src);
> +		else {

Tiny nit, not worth addressing on its own: the if branch should also
have curly braces.

Patrick

Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Patrick Steinhardt]

On Wed, Dec 17, 2025 at 02:23:40PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The preceding commit fixed the vulnerability whereas sideband messages
> (that are under the control of the remote server) could contain ANSI
> escape sequences that would be sent to the terminal verbatim.
> 
> However, this fix may not be desirable under all circumstances, e.g.
> when remote servers deliberately add coloring to their messages to
> increase their urgency.
> 
> To help with those use cases, give users a way to opt-out of the
> protections: `sideband.allowControlCharacters`.

I wonder whether this is a bit too broad. The only escape sequences that
I can see a valid use case for are color codes. So wouldn't it make
sense to discern color escape sequences from all other escape sequences
and allow users to only enable colors without also enabling all the
other, potentially more dangerous ones?

Edit: aha, you address this concern in the next commit. Nice :)

Patrick

Re: [PATCH v2 3/4] sideband: do allow ANSI color sequences by default

[Patrick Steinhardt]

On Wed, Dec 17, 2025 at 02:23:41PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> The preceding two commits introduced special handling of the sideband
> channel to neutralize ANSI escape sequences before sending the payload
> to the terminal, and `sideband.allowControlCharacters` to override that
> behavior.
> 
> However, as reported by brian m. carlson, some `pre-receive` hooks that
> are actively used in practice want to color their messages and therefore
> rely on the fact that Git passes them through to the terminal, even
> though they have no way to determine whether the receiving side can
> actually handle Escape sequences (think e.g. about the practice
> recommended by Git that third-party applications wishing to use Git
> functionality parse the output of Git commands).
> 
> In contrast to other ANSI escape sequences, it is highly unlikely that
> coloring sequences can be essential tools in attack vectors that mislead
> Git users e.g. by hiding crucial information.

The worst that they can do is to set up both fore- and background color
to be the same so that text isn't visible. But I think that's an okay
tradeoff.

> Therefore we can have both: Continue to allow ANSI coloring sequences to
> be passed to the terminal by default, and neutralize all other ANSI
> Escape sequences.

Makes sense.

> diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
> index 3fb5045cd7..e5b7383c7a 100644
> --- a/Documentation/config/sideband.txt
> +++ b/Documentation/config/sideband.txt
> @@ -1,5 +1,17 @@
>  sideband.allowControlCharacters::
>  	By default, control characters that are delivered via the sideband
> -	are masked, to prevent potentially unwanted ANSI escape sequences
> -	from being sent to the terminal. Use this config setting to override
> -	this behavior.
> +	are masked, except ANSI color sequences. This prevents potentially
> +	unwanted ANSI escape sequences from being sent to the terminal. Use
> +	this config setting to override this behavior:
> ++
> +--
> +	default::
> +	color::
> +		Allow ANSI color sequences, line feeds and horizontal tabs,
> +		but mask all other control characters. This is the default.
> +	false::
> +		Mask all control characters other than line feeds and
> +		horizontal tabs.
> +	true::
> +		Allow all control characters to be sent to the terminal.
> +--

Nit: I think that our modern doc style requires the values to use
backticks. E.g. "`default`::".

> diff --git a/sideband.c b/sideband.c
> index 997430f2ea..fb43008ab7 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -40,8 +45,26 @@ static int use_sideband_colors(void)
>  	if (use_sideband_colors_cached >= 0)
>  		return use_sideband_colors_cached;
>  
> -	git_config_get_bool("sideband.allowcontrolcharacters",
> -			    &allow_control_characters);
> +	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
> +	case 0: /* Boolean value */
> +		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
> +			ALLOW_NO_CONTROL_CHARACTERS;
> +		break;
> +	case -1: /* non-Boolean value */
> +		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
> +					      &value))
> +			; /* huh? `get_maybe_bool()` returned -1 */

This case is something that shouldn't happen in practice because we know
that the config ought to exist. I guess it _could_ indicate a race
condition, even though it's extremely unlikely to ever happen. So I was
thinking about whether we want to `BUG()` here, but I guess just
ignoring this is fine, as well.

> @@ -70,9 +93,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
>  		list_config_item(list, prefix, keywords[i].keyword);
>  }
>  
> +static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
> +{
> +	int i;
> +
> +	/*
> +	 * Valid ANSI color sequences are of the form
> +	 *
> +	 * ESC [ [<n> [; <n>]*] m
> +	 *
> +	 * These are part of the Select Graphic Rendition sequences which
> +	 * contain more than just color sequences, for more details see
> +	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
> +	 */
> +
> +	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
> +	    n < 3 || src[0] != '\x1b' || src[1] != '[')
> +		return 0;

This would break in case `allow_control_characters` allows _all_ ANSI
sequences. But that doesn't matter right now because the function is
only called via `strbuf_add_sanitized()` when we're sanitizing at least
some characters.

Might be worth though to add a call to `BUG()` in case we see an
unsupported value for `allow_control_characters`.

> +	for (i = 2; i < n; i++) {
> +		if (src[i] == 'm') {
> +			strbuf_add(dest, src, i + 1);
> +			return i;
> +		}
> +		if (!isdigit(src[i]) && src[i] != ';')
> +			break;
> +	}

Okay, so this loop scans until we find the final "m" character that
terminates the sequence. Looks good to me.

Patrick

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Patrick Steinhardt]

On Wed, Dec 17, 2025 at 02:23:42PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> Even though control sequences that erase characters are quite juicy for
> attack scenarios, where attackers are eager to hide traces of suspicious
> activities, during the review of the side band sanitizing patch series
> concerns were raised that there might be some legimitate scenarios where
> Git server's `pre-receive` hooks use those sequences in a benign way.
> 
> Control sequences to move the cursor can likewise be used to hide tracks
> by overwriting characters, and have been equally pointed out as having
> legitimate users.
> 
> Let's add options to let users opt into passing through those ANSI
> Escape sequences: `sideband.allowControlCharacters` now supports also
> `cursor` and `erase`, and it parses the value as a comma-separated list.

Hm, okay. I don't really see much of a reason to allow these, but now
that the code exists already I don't see a reason why we should remove
those options again.

> diff --git a/sideband.c b/sideband.c
> index fb43008ab7..725e24db0d 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -28,9 +28,43 @@ static struct keyword_entry keywords[] = {
>  static enum {
>  	ALLOW_NO_CONTROL_CHARACTERS = 0,
>  	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
> +	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
> +	ALLOW_ANSI_ERASE = 1<<2,
>  	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
> -	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
> -} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
> +	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
> +} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;

Nit, not worth addressing on its own: readability would be helped a bit
if the assignments were all aligned.

        static enum {
                ALLOW_NO_CONTROL_CHARACTERS  = 0,
                ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
                ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
                ALLOW_ANSI_ERASE             = 1<<2,
                ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
                ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
        } allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;

> +static inline int skip_prefix_in_csv(const char *value, const char *prefix,
> +				     const char **out)
> +{
> +	if (!skip_prefix(value, prefix, &value) ||
> +	    (*value && *value != ','))
> +		return 0;
> +	*out = value + !!*value;
> +	return 1;
> +}
> +
> +static void parse_allow_control_characters(const char *value)
> +{
> +	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
> +	while (*value) {
> +		if (skip_prefix_in_csv(value, "default", &value))
> +			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
> +		else if (skip_prefix_in_csv(value, "color", &value))
> +			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
> +		else if (skip_prefix_in_csv(value, "cursor", &value))
> +			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
> +		else if (skip_prefix_in_csv(value, "erase", &value))
> +			allow_control_characters |= ALLOW_ANSI_ERASE;
> +		else if (skip_prefix_in_csv(value, "true", &value))
> +			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
> +		else if (skip_prefix_in_csv(value, "false", &value))
> +			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;

Does it really make sense to also handle "true" and "false" here? I
would expect that those values can only be passed standalone.

> +		else
> +			warning(_("unrecognized value for `sideband."
> +				  "allowControlCharacters`: '%s'"), value);
> +	}
> +}

This could be simplified if we used e.g. `string_list_split()`. But on
the other hand it avoids allocations, so that's a nice benefit.

Patrick

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

On 2026-01-09 at 12:38:31, Patrick Steinhardt wrote:
> On Wed, Dec 17, 2025 at 02:23:42PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > Even though control sequences that erase characters are quite juicy for
> > attack scenarios, where attackers are eager to hide traces of suspicious
> > activities, during the review of the side band sanitizing patch series
> > concerns were raised that there might be some legimitate scenarios where
> > Git server's `pre-receive` hooks use those sequences in a benign way.
> > 
> > Control sequences to move the cursor can likewise be used to hide tracks
> > by overwriting characters, and have been equally pointed out as having
> > legitimate users.
> > 
> > Let's add options to let users opt into passing through those ANSI
> > Escape sequences: `sideband.allowControlCharacters` now supports also
> > `cursor` and `erase`, and it parses the value as a comma-separated list.
> 
> Hm, okay. I don't really see much of a reason to allow these, but now
> that the code exists already I don't see a reason why we should remove
> those options again.

The reason these sequences, along with other sequences not mentioned in
this series, are useful is because people run tools like build tools
(e.g., Cargo) or linters in pre-receive hooks and print the output and
those use a substantial portion of possible escape sequences.  I did a
brief survey sometime back of pre-receive hooks on GitHub to see what
escape sequences were in use.

I think Heroku has a push-to-deploy technique that leverages this
approach to build and deploy your app, for instance.

This is one of the reasons that I was opposed to this series: it tends
to break what is a very common use case.  Certainly it is not as common
for cloud-based forge environments, but it is very common for people to
do these kinds of things in self-hosted forge environments (where custom
pre-receive hooks are commonly used) or in non-forge environments like
push-to-deploy.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Jeff King]

On Sat, Jan 10, 2026 at 05:26:04PM +0000, brian m. carlson wrote:

> The reason these sequences, along with other sequences not mentioned in
> this series, are useful is because people run tools like build tools
> (e.g., Cargo) or linters in pre-receive hooks and print the output and
> those use a substantial portion of possible escape sequences.  I did a
> brief survey sometime back of pre-receive hooks on GitHub to see what
> escape sequences were in use.
> 
> I think Heroku has a push-to-deploy technique that leverages this
> approach to build and deploy your app, for instance.
> 
> This is one of the reasons that I was opposed to this series: it tends
> to break what is a very common use case.  Certainly it is not as common
> for cloud-based forge environments, but it is very common for people to
> do these kinds of things in self-hosted forge environments (where custom
> pre-receive hooks are commonly used) or in non-forge environments like
> push-to-deploy.

I also share your concern that real-world cases may be relying on these.
But I am also sympathetic that some people may prefer to risk breakage
(or ugliness) if it might protect them from misleading or mischievous
terminal trickery.

Is there any reason we cannot introduce the new functionality as a
config option but _not_ enable it by default?

That gives people the tools to protect themselves if they want to bear
the potential cost. It just feels a shame to deny them the tool because
we can't agree on the default.

-Peff

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Is there any reason we cannot introduce the new functionality as a
> config option but _not_ enable it by default?
>
> That gives people the tools to protect themselves if they want to bear
> the potential cost. It just feels a shame to deny them the tool because
> we can't agree on the default.

Yeah, I like the suggestion---making it opt-in would have much less
chance of breaking set-up people are relying on all of a sudden.

Thanks.

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

On 2026-01-15 at 21:14:48, Jeff King wrote:
> Is there any reason we cannot introduce the new functionality as a
> config option but _not_ enable it by default?
> 
> That gives people the tools to protect themselves if they want to bear
> the potential cost. It just feels a shame to deny them the tool because
> we can't agree on the default.

Yes, I think that would be a fine and reasonable approach.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin]

Hi Junio, Jeff, and other interested parties,

On Thu, 15 Jan 2026, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Is there any reason we cannot introduce the new functionality as a
> > config option but _not_ enable it by default?
> >
> > That gives people the tools to protect themselves if they want to bear
> > the potential cost. It just feels a shame to deny them the tool because
> > we can't agree on the default.
> 
> Yeah, I like the suggestion---making it opt-in would have much less
> chance of breaking set-up people are relying on all of a sudden.

Can you help me understand how these existing use cases (which are not
actually in wide-spread use) aren't broken by design, given that they have
no chance to ensure that their ANSI sequences go to an actual terminal
that can understand those sequences?

As such, it looks to me as if they have a valid goal, but go about it in a
way that is easily improved: If they want color in their sideband output,
then Git has to be taught about it, much in the same way as bf1a11f0a10
(sideband: highlight keywords in remote sideband output, 2018-08-07)
taught Git to highlight keywords in the remote sideband output. That is
the actual correct way to do this, not by expecting Git to pass through
all bytes to the terminal without sanitizing, which is a well-known worst
practice (not even GNU tar does that when listing the contents of an
archive, nor does cURL do that, just to list two of the command-line
programs that sanitize properly what they pass on to the terminal).

Given that those use cases are rare (none of the popular Git forges
support this!), and that it is a security issue, I still think that the
default should be as I proposed: To pass through only a small subset of
ANSI control sequences that you gentle people already agreed should be
safe.

Keep in mind that I already accommodated the concern that has been raised
over and over again about _a few_ pre-receive hooks out there making their
errors colorful, by making the default so that color sequences are
actually passed through! In light of that, I am a bit puzzled how much
more you want to be passed through by default, it sounds as if you want to
turn off all sanitizing by default, even if not a single of those
(uncommon) use cases that have been raised need anything else than ANSI
color sequences to be passed through, and even if passing through control
sequences to the terminal completely unsanitized is insecure.

Ciao,
Johannes

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Patrick Steinhardt]

On Fri, Jan 16, 2026 at 12:12:47AM +0100, Johannes Schindelin wrote:
> Hi Junio, Jeff, and other interested parties,
> 
> On Thu, 15 Jan 2026, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > > Is there any reason we cannot introduce the new functionality as a
> > > config option but _not_ enable it by default?
> > >
> > > That gives people the tools to protect themselves if they want to bear
> > > the potential cost. It just feels a shame to deny them the tool because
> > > we can't agree on the default.
> > 
> > Yeah, I like the suggestion---making it opt-in would have much less
> > chance of breaking set-up people are relying on all of a sudden.
> 
> Can you help me understand how these existing use cases (which are not
> actually in wide-spread use) aren't broken by design, given that they have
> no chance to ensure that their ANSI sequences go to an actual terminal
> that can understand those sequences?
> 
> As such, it looks to me as if they have a valid goal, but go about it in a
> way that is easily improved: If they want color in their sideband output,
> then Git has to be taught about it, much in the same way as bf1a11f0a10
> (sideband: highlight keywords in remote sideband output, 2018-08-07)
> taught Git to highlight keywords in the remote sideband output. That is
> the actual correct way to do this, not by expecting Git to pass through
> all bytes to the terminal without sanitizing, which is a well-known worst
> practice (not even GNU tar does that when listing the contents of an
> archive, nor does cURL do that, just to list two of the command-line
> programs that sanitize properly what they pass on to the terminal).
> 
> Given that those use cases are rare (none of the popular Git forges
> support this!), and that it is a security issue, I still think that the
> default should be as I proposed: To pass through only a small subset of
> ANSI control sequences that you gentle people already agreed should be
> safe.

I have to agree with Johannes here. There's been way to many CVEs
assigned to terminal emulators out there that allowed arbitrary code
execution via ANSI escape sequences. Sure, you could argue that this is
an issue in the terminal emulator that needs to be fixed, and that is
certainly true. But we are significantly increasing the attack surface
if we don't sanitize escape sequences. And even when working as designed
I would claim that a lot of the escape sequences can cause active harm
[1][2][3].

So I would think that we should have behaviour in Git that is safe by
default, not safe if you know that the options happen to exist. Because
if we do the latter, then the majority of people will never enable it,
and I'm just not sure whether it's a good idea to increase the attack
surface for the majority of our users only to enable a small set of
niche edge cases. Doubly so when those niche edge cases can be made to
work again with an opt-out.

Patrick

[1]: https://cwe.mitre.org/data/definitions/150.html
[2]: https://www.infosecmatter.com/terminal-escape-injection/
[3]: https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emulators-with-ansi-escape-characters

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Ondrej Pohorelsky]

Hi, I just want to weight in from the downstream maintainer POV.
We've been carrying the patches Johannes has created in Fedora, CentOS
and RHEL for at least half a year now.
The only change I did is to make the new behavior opt-in by default
and give the RHEL customers a release note explaining it.
So far, I haven't heard about any issue with the patch, but sadly I
have no idea how widely it is used.

I think the patches proposed are making sense, and they should be
merged. Even having them as opt-in is better than not having them
merged at all.
In my opinion, giving a user option to harden against this kind of
attacks shouldn't be blocked by the discussion about what is the right
default.



On Fri, Jan 16, 2026 at 7:45 AM Patrick Steinhardt <ps@pks.im> wrote:
>
> On Fri, Jan 16, 2026 at 12:12:47AM +0100, Johannes Schindelin wrote:
> > Hi Junio, Jeff, and other interested parties,
> >
> > On Thu, 15 Jan 2026, Junio C Hamano wrote:
> >
> > > Jeff King <peff@peff.net> writes:
> > >
> > > > Is there any reason we cannot introduce the new functionality as a
> > > > config option but _not_ enable it by default?
> > > >
> > > > That gives people the tools to protect themselves if they want to bear
> > > > the potential cost. It just feels a shame to deny them the tool because
> > > > we can't agree on the default.
> > >
> > > Yeah, I like the suggestion---making it opt-in would have much less
> > > chance of breaking set-up people are relying on all of a sudden.
> >
> > Can you help me understand how these existing use cases (which are not
> > actually in wide-spread use) aren't broken by design, given that they have
> > no chance to ensure that their ANSI sequences go to an actual terminal
> > that can understand those sequences?
> >
> > As such, it looks to me as if they have a valid goal, but go about it in a
> > way that is easily improved: If they want color in their sideband output,
> > then Git has to be taught about it, much in the same way as bf1a11f0a10
> > (sideband: highlight keywords in remote sideband output, 2018-08-07)
> > taught Git to highlight keywords in the remote sideband output. That is
> > the actual correct way to do this, not by expecting Git to pass through
> > all bytes to the terminal without sanitizing, which is a well-known worst
> > practice (not even GNU tar does that when listing the contents of an
> > archive, nor does cURL do that, just to list two of the command-line
> > programs that sanitize properly what they pass on to the terminal).
> >
> > Given that those use cases are rare (none of the popular Git forges
> > support this!), and that it is a security issue, I still think that the
> > default should be as I proposed: To pass through only a small subset of
> > ANSI control sequences that you gentle people already agreed should be
> > safe.
>
> I have to agree with Johannes here. There's been way to many CVEs
> assigned to terminal emulators out there that allowed arbitrary code
> execution via ANSI escape sequences. Sure, you could argue that this is
> an issue in the terminal emulator that needs to be fixed, and that is
> certainly true. But we are significantly increasing the attack surface
> if we don't sanitize escape sequences. And even when working as designed
> I would claim that a lot of the escape sequences can cause active harm
> [1][2][3].
>
> So I would think that we should have behaviour in Git that is safe by
> default, not safe if you know that the options happen to exist. Because
> if we do the latter, then the majority of people will never enable it,
> and I'm just not sure whether it's a good idea to increase the attack
> surface for the majority of our users only to enable a small set of
> niche edge cases. Doubly so when those niche edge cases can be made to
> work again with an opt-out.
>
> Patrick
>
> [1]: https://cwe.mitre.org/data/definitions/150.html
> [2]: https://www.infosecmatter.com/terminal-escape-injection/
> [3]: https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emulators-with-ansi-escape-characters
>


--

Ondřej Pohořelský

Software Engineer

Red Hat

opohorel@redhat.com

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Ondrej Pohorelsky <opohorel@redhat.com> writes:

> Hi, I just want to weight in from the downstream maintainer POV.
> We've been carrying the patches Johannes has created in Fedora, CentOS
> and RHEL for at least half a year now.
> The only change I did is to make the new behavior opt-in by default
> and give the RHEL customers a release note explaining it.

Thanks for your great input.  FWIW, I do not think anybody around
here is against "opt-in with a note" approach at all.

> I think the patches proposed are making sense, and they should be
> merged. Even having them as opt-in is better than not having them
> merged at all.

I do not think anybody disagrees with this sentiment.  Back when the
patches originally was discussed on the public list here, nobody was
against adding it as an _optional_ feature to filter some byte
sequences out of the end-user's data stream, and the review comments
that led to the topic marked to be "expecting a reroll", if I recall
correctly, were all about "why would we make this on by default?"
Peff's message that reignited the topic this time around is also
about the same.

We are still hearing from Dscho that he cannot think of a scenario
where making this mandatory with opt-out would break existing
legitimate setup people may have (I am paraphrasing [*]), but I
think that is aiming in the wrong direction.  It does not matter if
you consider the approach your users take is "broken by design"; as
long as it works for them in their (limited) settings, it is a valid
arrangement to send arbitrary byte sequence over the sideband even
it happens to include ANSI escapes and other "curiosities".  We have
in no position to unilaterally break them, telling them that we left
a way open for them to disable.  That is not how to deliver features.

I strongly suspect that the reason why you made "The only
change---opt-in by default" is from the same reasoning as above.  Do
not break end-users' set-up.  As long as it works for them, it is
not "broken by design" to them, and it is irresponsible to break
their set-up.

But an opt-in way to filter suspicious byte sequences is a good
thing, as such a mechanism did not exist before.

So in short, yes, everybody around here agrees with you that the
feature as an opt-in is a great addition.


[Footnote]

 * Here is from <c0af9072-cf21-a7e2-5b78-eb70217b462c@gmx.de>
   without my paraphrasing.

   """Can you help me understand how these existing use cases (which
   are not actually in wide-spread use) aren't broken by design, given
   that they have no chance to ensure that their ANSI sequences go to
   an actual terminal that can understand those sequences?"""

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin]

Hi Junio,

On Fri, 16 Jan 2026, Junio C Hamano wrote:

> Ondrej Pohorelsky <opohorel@redhat.com> writes:
> 
> > Hi, I just want to weight in from the downstream maintainer POV.
> > We've been carrying the patches Johannes has created in Fedora, CentOS
> > and RHEL for at least half a year now.
> > The only change I did is to make the new behavior opt-in by default
> > and give the RHEL customers a release note explaining it.
> 
> Thanks for your great input.

Well, I have another great input: Git for Windows (and as a consequence,
Microsoft Git) has been shipping with the original version of these
patches for over a year now. There has been not a single report that the
behavior (safe by default) has caused any problem whatsoever. Not one.

> FWIW, I do not think anybody around here is against "opt-in with a note"
> approach at all.

Does what I say not count? Additionally, I think you misinterpreted
Patrick's reply, who pointed out that Git should be safe by default (i.e.
"opt-out").

Let me state quite clearly that even that unfortunate phrasing of an
"opt-in vs opt-out" needs to be reconsidered: It makes it sound as if it
was a choice of all vs nothing. But that's far from the truth!

This patch series not only introduces support for sanitizing the sideband
channel, as should have been the practice from the get-go to make Git
safe. It introduces several levels of sanitizing. And by default, it
passes through the ANSI color sequences, the very thing that was pointed
out as an existing use case.

If you can point me to an existing, legitimate use case where this would
not satisfy both users who wish to be safe as well as the oft-mentioned
existing use cases that play games with the sideband, I am happy to
discuss it further.

> > I think the patches proposed are making sense, and they should be
> > merged. Even having them as opt-in is better than not having them
> > merged at all.
> 
> I do not think anybody disagrees with this sentiment.  Back when the
> patches originally was discussed on the public list here, nobody was
> against adding it as an _optional_ feature to filter some byte
> sequences out of the end-user's data stream, and the review comments
> that led to the topic marked to be "expecting a reroll", if I recall
> correctly, were all about "why would we make this on by default?"
> Peff's message that reignited the topic this time around is also
> about the same.

Let me challenge you on that. Let me ask you why, when it is a well-known
best practice to santizie untrusted bytes before sending them to a
terminal, Git should do the opposite by default?

Unless I am completely misunderstanding you and by "opt-in", you mean to
opt into the unsafe behavior to pass through all the control characters
without filtering?

> We are still hearing from Dscho that he cannot think of a scenario
> where making this mandatory with opt-out would break existing
> legitimate setup people may have (I am paraphrasing [*]), but I
> think that is aiming in the wrong direction.  It does not matter if
> you consider the approach your users take is "broken by design"; as
> long as it works for them in their (limited) settings, it is a valid
> arrangement to send arbitrary byte sequence over the sideband even
> it happens to include ANSI escapes and other "curiosities".  We have
> in no position to unilaterally break them, telling them that we left
> a way open for them to disable.  That is not how to deliver features.

If this were a feature that is nice to have, I would agree with you that
it is not how to deliver features.

In this instance, we are talking about security, though. ANSI control
sequences have been used to execute successful attacks. If Git allows
remote servers to mislead users to think that Git is asking for their
input, it is unsafe by default. And that's what this patch series tries to
fix. Not by asking users who wish to be safe to read the release notes and
configure a setting. But by having a safe default in the first place.

Ciao,
Johannes

> I strongly suspect that the reason why you made "The only
> change---opt-in by default" is from the same reasoning as above.  Do
> not break end-users' set-up.  As long as it works for them, it is
> not "broken by design" to them, and it is irresponsible to break
> their set-up.
> 
> But an opt-in way to filter suspicious byte sequences is a good
> thing, as such a mechanism did not exist before.
> 
> So in short, yes, everybody around here agrees with you that the
> feature as an opt-in is a great addition.
> 
> [Footnote]
> 
>  * Here is from <c0af9072-cf21-a7e2-5b78-eb70217b462c@gmx.de>
>    without my paraphrasing.
> 
>    """Can you help me understand how these existing use cases (which
>    are not actually in wide-spread use) aren't broken by design, given
>    that they have no chance to ensure that their ANSI sequences go to
>    an actual terminal that can understand those sequences?"""
> 
> 

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> FWIW, I do not think anybody around here is against "opt-in with a note"
>> approach at all.
>
> Does what I say not count? Additionally, I think you misinterpreted
> Patrick's reply, who pointed out that Git should be safe by default (i.e.
> "opt-out").

What I meant was there is nobody who does not want these filtering
changes under any shape.  Everybody is OK with these filtering, even
those of us who do not want to give unnecessary regressions to end
users, as long as it is opt-in.

Unless you and Patrick thinks we should not add the filtering
feature unless we enable it by default, that is.

Re: [PATCH v2 2/4] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin]

Hi Junio,

On Fri, 19 Dec 2025, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Good idea! What do you think about something like this?
> 
> It may be easier to hack up to piggyback on the http.*.variable
> infrastructure, but I do not like the smell of it very much, because
> the implementation ties it too tightly to the http transport; I
> think this should live in one layer up (transport?).
> 
> > If this is the direction you're thinking, I'll polish it and integrate it
> > into v3.
> 
> In other words, it would be more like sideband.allowEscapeSequences
> that is overridden by sideband.<url>.allowEscapeSequences was what I
> had in mind.  Or even transfer.allowEscapeSequencesInSideband that
> is overridden by transfer.<url>.allowEscapeSequencesInSideband.

That was quite a bit trickier than I hoped for. But here it finally is:

-- snip --
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: [PATCH] sideband: offer to configure sanitizing on a per-URL basis

The main objection against sanitizing the sideband that was raised
during the review of the sideband sanitizing patches, first on the
git-security mailing list, then on the public mailing list, was that
there are some setups where server-side `pre-receive` hooks want to
error out, giving colorful messages to the users on the client side (if
they are not redirecting the output into a file, that is).

To avoid breaking such setups, the default chosen by the sideband
sanitizing patches is to pass through ANSI color sequences.

Still, there might be some use case out there where that is not enough.
Therefore the `sideband.allowControlCharacters` config setting allows
for configuring  levels of sanitizing.

As Junio Hamano pointed out, to keep users safe by default, we need to
be able to scope this to some servers because while a user may trust
their company's Git server, the same might not apply to other Git
servers.

To allow for this, let's imitate the way `http.<url>.*` offers
to scope config settings to certain URLs, by letting users
override the `sideband.allowControlCharacters` setting via
`sideband.<url>.allowControlCharacters`.

Suggested-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   |  4 ++
 sideband.c                          | 69 +++++++++++++++++++++--------
 sideband.h                          | 14 ++++++
 t/t5409-colorize-remote-messages.sh | 24 ++++++++++
 transport.c                         |  3 ++
 5 files changed, 96 insertions(+), 18 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 8eb7656cdd2..cc2cc463bef 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -22,3 +22,7 @@ sideband.allowControlCharacters::
 	true::
 		Allow all control characters to be sent to the terminal.
 --
+
+sideband.<url>.*::
+	Apply the `sideband.*` option selectively to specific URLs. The
+	same URL matching logic applies as for `http.<url>.*` settings.
diff --git a/sideband.c b/sideband.c
index 725e24db0db..e856981ea55 100644
--- a/sideband.c
+++ b/sideband.c
@@ -9,6 +9,7 @@
 #include "help.h"
 #include "pkt-line.h"
 #include "write-or-die.h"
+#include "urlmatch.h"
 
 struct keyword_entry {
 	/*
@@ -26,13 +27,14 @@ static struct keyword_entry keywords[] = {
 };
 
 static enum {
+	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
 	ALLOW_NO_CONTROL_CHARACTERS = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
 	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
 	ALLOW_ANSI_ERASE = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
 	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
-} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+} allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 				     const char **out)
@@ -44,8 +46,19 @@ static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 	return 1;
 }
 
-static void parse_allow_control_characters(const char *value)
+int sideband_allow_control_characters_config(const char *var, const char *value)
 {
+	switch (git_parse_maybe_bool(value)) {
+	case 0:
+		allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		return 0;
+	case 1:
+		allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		return 0;
+	default:
+		break;
+	}
+
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
 		if (skip_prefix_in_csv(value, "default", &value))
@@ -61,9 +74,37 @@ static void parse_allow_control_characters(const char *value)
 		else if (skip_prefix_in_csv(value, "false", &value))
 			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			warning(_("unrecognized value for '%s': '%s'"), var, value);
 	}
+	return 0;
+}
+
+static int sideband_config_callback(const char *var, const char *value,
+				    const struct config_context *ctx UNUSED,
+				    void *data UNUSED)
+{
+	if (!strcmp(var, "sideband.allowcontrolcharacters"))
+		return sideband_allow_control_characters_config(var, value);
+
+	return 0;
+}
+
+void sideband_apply_url_config(const char *url)
+{
+	struct urlmatch_config config = URLMATCH_CONFIG_INIT;
+	char *normalized_url;
+
+	if (!url)
+		BUG("must not call sideband_apply_url_config(NULL)");
+
+	config.section = "sideband";
+	config.collect_fn = sideband_config_callback;
+
+	normalized_url = url_normalize(url, &config.url);
+	git_config(urlmatch_config_entry, &config);
+	free(normalized_url);
+	string_list_clear(&config.vars, 1);
+	urlmatch_config_release(&config);
 }
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
@@ -79,20 +120,12 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
-	case 0: /* Boolean value */
-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
-			ALLOW_NO_CONTROL_CHARACTERS;
-		break;
-	case -1: /* non-Boolean value */
-		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
-					      &value))
-			; /* huh? `get_maybe_bool()` returned -1 */
-		else
-			parse_allow_control_characters(value);
-		break;
-	default:
-		break; /* not configured */
+	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
+		if (!git_config_get_value("sideband.allowcontrolcharacters", &value))
+			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
+
+		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
 	}
 
 	if (!git_config_get_string_tmp(key, &value))
diff --git a/sideband.h b/sideband.h
index 5a25331be55..d15fa4015fa 100644
--- a/sideband.h
+++ b/sideband.h
@@ -30,4 +30,18 @@ int demultiplex_sideband(const char *me, int status,
 
 void send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
 
+/*
+ * Apply sideband configuration for the given URL. This should be called
+ * when a transport is created to allow URL-specific configuration of
+ * sideband behavior (e.g., sideband.<url>.allowControlCharacters).
+ */
+void sideband_apply_url_config(const char *url);
+
+/*
+ * Parse and set the sideband allow control characters configuration.
+ * The var parameter should be the key name (without section prefix).
+ * Returns 0 if the variable was recognized and handled, non-zero otherwise.
+ */
+int sideband_allow_control_characters_config(const char *var, const char *value);
+
 #endif
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index c3e4e143627..1d039cbdafb 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -167,4 +167,28 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_grep ! "\\^\\[\\[G" decoded
 '
 
+test_expect_success 'allow all control sequences for a specific URL' '
+	write_script .git/eraser <<-\EOF &&
+	printf "error: Ohai!\\r\\033[K" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./eraser &&
+	test_commit one-more-please &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep "\\^\\[\\[K" decoded &&
+
+	rm -rf throw-away &&
+	git -c "sideband.file://.allowControlCharacters=true" \
+		clone --no-local "file://$PWD" throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded
+'
+
 test_done
diff --git a/transport.c b/transport.c
index 1098bbd60e4..e19536c9c6b 100644
--- a/transport.c
+++ b/transport.c
@@ -28,6 +28,7 @@
 #include "object-name.h"
 #include "color.h"
 #include "bundle-uri.h"
+#include "sideband.h"
 
 static int transport_use_color = -1;
 static char transport_colors[][COLOR_MAXLEN] = {
@@ -1210,6 +1211,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1];
 
+	sideband_apply_url_config(ret->url);
+
 	return ret;
 }
 
-- snap --

That should address this particular concern of yours.

> >>  - It may no longer matter but a remote repository that may send
> >>    messages as strings encoded in ISO/IEC 2022 would need to set
> >>    this, merely to make the messages human-readable.  There may be
> >>    other reasons the trusted repositories want to send "escape
> >>    sequences".
> >
> > If the remote side has no way to determine whether the client side is
> > connected to a terminal or not (which we have already established in this
> > thread), it has even less chance to determine which character encoding is
> > in use...
> 
> Then I think you need to re-read brian's
> 
>   https://lore.kernel.org/git/aS-D5lD2Kk6BHNIl@fruit.crustytoothpaste.net/

Oh, but brian described a scenario that is quite different: it is using
SSH. And there, the hook has quite literally the ability to verify that
the output goes to a terminal. It is also implicitly much more trustable
than a random HTTPS server because if you have SSH credentials to
authenticate with a server, there is already a much stronger trust
relationship here. That scenario is far away from some repository on
GitHub requiring a recursive clone that then points to some totally
untrustworthy HTTPS server hosted by the attacker.

> In any case, I do not think ISO/IEC 2022 matters as much as it used
> to back when the reencode_string_iconv() was written (which was the
> topic of another thread regarding the broken iconv on macOS wrt
> 2022).  But even if we limit ourselves to UTF-8, brian's point that
> applications do assume certain characteristics on its clients and
> implements unportable stuff.  A project targetting developers and/or
> users from certain locale may use their own hooks that assumes the
> clients understands strings in certain language in certain encoding.
> 
> And to serve these projects better, classes like "pass colors",
> "pass cursor movements", might help than just "pass everything" vs
> "deny everything", but we probably want to try to keep it as simple
> as possible; trying to make it finer grained with extra complexity
> would only make our efforts look like whack-a-mole X-<.

Well, I only introduced that complexity because you asked for it on the
git-security mailing list. You offered concerns that an all-or-nothing
escape hatch was not fine-grained enough. It was hard enough for me to
tickle out what granularity exactly would be needed in addition to appease
the concerns, and obviously even what I did was not enough to be
accepted...

> >> It might even be a good idea to make the default setting of this
> >> variable "allow", except for the initial connections to repositories
> >> (i.e., "git clone $URL", and "git fetch/ls-remote $URL" with an
> >> explicit $URL without using a nickname recorded in our .git/config),
> >> as visiting a potentially malicious remote repository you are not
> >> familiar with may not be uncommon, and users may deserve protection
> >> over inconvenience.
> >> 
> >> But once the user establishes a working relationship with a remote
> >> repository, would it be a lot more common to trust the contents
> >> there than be on the lookout that the repository may spew bad
> >> strings of bytes at your standard error stream, I have to wonder.
> 
> >   tl;dr remote servers don't get more trustworthy just by successfully
> >   serving clones.
> 
> The "successfully serving clone" has nothing to do with the reason
> why I suggested to deny by default in "clone" and anything that gets
> $URL not remote nickname.  I am roughly equating the fact that the
> user cloned *and* *then* continues to interact with the project that
> is served from that remote repository (hence using the remote
> nickname) with the willingness by the user to trust that particular
> remote repository.

Such a willingness to trust might be only because nothing bad happened
during the clone, though. In which case we made things worse that way, not
better.

Ciao,
Johannes

Re: [PATCH v2 1/4] sideband: mask control characters

[Johannes Schindelin]

Hi Patrick,

On Fri, 9 Jan 2026, Patrick Steinhardt wrote:

> On Wed, Dec 17, 2025 at 02:23:39PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > The output of `git clone` is a vital component for understanding what
> > has happened when things go wrong. However, these logs are partially
> > under the control of the remote server (via the "sideband", which
> > typically contains what the remote `git pack-objects` process sends to
> > `stderr`), and is currently not sanitized by Git.
> > 
> > This makes Git susceptible to ANSI escape sequence injection (see
> > CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
> > attackers to corrupt terminal state, to hide information, and even to
> > insert characters into the input buffer (i.e. as if the user had typed
> > those characters).
> > 
> > To plug this vulnerability, disallow any control character in the
> > sideband, replacing them instead with the common `^<letter/symbol>`
> > (e.g. `^[` for `\x1b`, `^A` for `\x01`).
> > 
> > There is likely a need for more fine-grained controls instead of using a
> > "heavy hammer" like this, which will be introduced subsequently.
> 
> Most notably color codes, I assume.

Precisely.

> > diff --git a/sideband.c b/sideband.c
> > index 02805573fa..fc1805dcf8 100644
> > --- a/sideband.c
> > +++ b/sideband.c
> > @@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
> >  		list_config_item(list, prefix, keywords[i].keyword);
> >  }
> >  
> > +static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
> 
> Shouldn't `n` be of type `size_t`? I guess the answer is "maybe", as
> `maybe_colorize_sideband()` also accepts `int n` with a big comment
> explaining why that's okay. Ultimately, the reason is that we accept
> pkt-lines, so every line is limited to at most 64kB anyway.

Exactly. I did not want to use a different data type for the parameter
that is essentially just passed through.

> > +{
> > +	strbuf_grow(dest, n);
> > +	for (; n && *src; src++, n--) {
> > +		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
> > +			strbuf_addch(dest, *src);
> > +		else {
> 
> Tiny nit, not worth addressing on its own: the if branch should also
> have curly braces.

Will address in the next iteration.

Ciao,
Johannes

Re: [PATCH v2 3/4] sideband: do allow ANSI color sequences by default

[Johannes Schindelin]

Hi Patrick,

On Fri, 9 Jan 2026, Patrick Steinhardt wrote:

> On Wed, Dec 17, 2025 at 02:23:41PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > The preceding two commits introduced special handling of the sideband
> > channel to neutralize ANSI escape sequences before sending the payload
> > to the terminal, and `sideband.allowControlCharacters` to override that
> > behavior.
> > 
> > However, as reported by brian m. carlson, some `pre-receive` hooks that
> > are actively used in practice want to color their messages and therefore
> > rely on the fact that Git passes them through to the terminal, even
> > though they have no way to determine whether the receiving side can
> > actually handle Escape sequences (think e.g. about the practice
> > recommended by Git that third-party applications wishing to use Git
> > functionality parse the output of Git commands).
> > 
> > In contrast to other ANSI escape sequences, it is highly unlikely that
> > coloring sequences can be essential tools in attack vectors that mislead
> > Git users e.g. by hiding crucial information.
> 
> The worst that they can do is to set up both fore- and background color
> to be the same so that text isn't visible. But I think that's an okay
> tradeoff.

Indeed.

The major concern here is to hide the fact from the user that Git already
exited and that what they see in their terminal is not actually Git asking
them to input something.

Technically, this would be possible by setting the text to "invisible"
(which would be a fine thing when pretending to ask for a password,
anyway). But without the ability to move the cursor, attackers will have a
much harder time to cover their tracks.

> > Therefore we can have both: Continue to allow ANSI coloring sequences to
> > be passed to the terminal by default, and neutralize all other ANSI
> > Escape sequences.
> 
> Makes sense.
> 
> > diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
> > index 3fb5045cd7..e5b7383c7a 100644
> > --- a/Documentation/config/sideband.txt
> > +++ b/Documentation/config/sideband.txt
> > @@ -1,5 +1,17 @@
> >  sideband.allowControlCharacters::
> >  	By default, control characters that are delivered via the sideband
> > -	are masked, to prevent potentially unwanted ANSI escape sequences
> > -	from being sent to the terminal. Use this config setting to override
> > -	this behavior.
> > +	are masked, except ANSI color sequences. This prevents potentially
> > +	unwanted ANSI escape sequences from being sent to the terminal. Use
> > +	this config setting to override this behavior:
> > ++
> > +--
> > +	default::
> > +	color::
> > +		Allow ANSI color sequences, line feeds and horizontal tabs,
> > +		but mask all other control characters. This is the default.
> > +	false::
> > +		Mask all control characters other than line feeds and
> > +		horizontal tabs.
> > +	true::
> > +		Allow all control characters to be sent to the terminal.
> > +--
> 
> Nit: I think that our modern doc style requires the values to use
> backticks. E.g. "`default`::".

Will change.

> > diff --git a/sideband.c b/sideband.c
> > index 997430f2ea..fb43008ab7 100644
> > --- a/sideband.c
> > +++ b/sideband.c
> > @@ -40,8 +45,26 @@ static int use_sideband_colors(void)
> >  	if (use_sideband_colors_cached >= 0)
> >  		return use_sideband_colors_cached;
> >  
> > -	git_config_get_bool("sideband.allowcontrolcharacters",
> > -			    &allow_control_characters);
> > +	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
> > +	case 0: /* Boolean value */
> > +		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
> > +			ALLOW_NO_CONTROL_CHARACTERS;
> > +		break;
> > +	case -1: /* non-Boolean value */
> > +		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
> > +					      &value))
> > +			; /* huh? `get_maybe_bool()` returned -1 */
> 
> This case is something that shouldn't happen in practice because we know
> that the config ought to exist. I guess it _could_ indicate a race
> condition, even though it's extremely unlikely to ever happen. So I was
> thinking about whether we want to `BUG()` here, but I guess just
> ignoring this is fine, as well.

I don't think that we can even get into a race condition because the
config is cached after it is read.

> > @@ -70,9 +93,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
> >  		list_config_item(list, prefix, keywords[i].keyword);
> >  }
> >  
> > +static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
> > +{
> > +	int i;
> > +
> > +	/*
> > +	 * Valid ANSI color sequences are of the form
> > +	 *
> > +	 * ESC [ [<n> [; <n>]*] m
> > +	 *
> > +	 * These are part of the Select Graphic Rendition sequences which
> > +	 * contain more than just color sequences, for more details see
> > +	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
> > +	 */
> > +
> > +	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
> > +	    n < 3 || src[0] != '\x1b' || src[1] != '[')
> > +		return 0;
> 
> This would break in case `allow_control_characters` allows _all_ ANSI
> sequences. But that doesn't matter right now because the function is
> only called via `strbuf_add_sanitized()` when we're sanitizing at least
> some characters.
> 
> Might be worth though to add a call to `BUG()` in case we see an
> unsupported value for `allow_control_characters`.

Later patches change the logic, though, to make `allow_control_characters`
a bit field. So maybe it can be left as-is here?

> 
> > +	for (i = 2; i < n; i++) {
> > +		if (src[i] == 'm') {
> > +			strbuf_add(dest, src, i + 1);
> > +			return i;
> > +		}
> > +		if (!isdigit(src[i]) && src[i] != ';')
> > +			break;
> > +	}
> 
> Okay, so this loop scans until we find the final "m" character that
> terminates the sequence. Looks good to me.

Thank you for your review!
Johannes

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin]

Hi Patrick,

On Fri, 9 Jan 2026, Patrick Steinhardt wrote:

> On Wed, Dec 17, 2025 at 02:23:42PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > Even though control sequences that erase characters are quite juicy for
> > attack scenarios, where attackers are eager to hide traces of suspicious
> > activities, during the review of the side band sanitizing patch series
> > concerns were raised that there might be some legimitate scenarios where
> > Git server's `pre-receive` hooks use those sequences in a benign way.
> > 
> > Control sequences to move the cursor can likewise be used to hide tracks
> > by overwriting characters, and have been equally pointed out as having
> > legitimate users.
> > 
> > Let's add options to let users opt into passing through those ANSI
> > Escape sequences: `sideband.allowControlCharacters` now supports also
> > `cursor` and `erase`, and it parses the value as a comma-separated list.
> 
> Hm, okay. I don't really see much of a reason to allow these, but now
> that the code exists already I don't see a reason why we should remove
> those options again.

I agree that the feedback that elicited this patch did not specify any
concrete use case where this might be necessary. I basically implemented
this only to alleviate the reviewer feedback more than any real-world
issue.

> 
> > diff --git a/sideband.c b/sideband.c
> > index fb43008ab7..725e24db0d 100644
> > --- a/sideband.c
> > +++ b/sideband.c
> > @@ -28,9 +28,43 @@ static struct keyword_entry keywords[] = {
> >  static enum {
> >  	ALLOW_NO_CONTROL_CHARACTERS = 0,
> >  	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
> > +	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
> > +	ALLOW_ANSI_ERASE = 1<<2,
> >  	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
> > -	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
> > -} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
> > +	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
> > +} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
> 
> Nit, not worth addressing on its own: readability would be helped a bit
> if the assignments were all aligned.
> 
>         static enum {
>                 ALLOW_NO_CONTROL_CHARACTERS  = 0,
>                 ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
>                 ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
>                 ALLOW_ANSI_ERASE             = 1<<2,
>                 ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
>                 ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
>         } allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;

I like that suggestion. Will change it.

> > +static inline int skip_prefix_in_csv(const char *value, const char *prefix,
> > +				     const char **out)
> > +{
> > +	if (!skip_prefix(value, prefix, &value) ||
> > +	    (*value && *value != ','))
> > +		return 0;
> > +	*out = value + !!*value;
> > +	return 1;
> > +}
> > +
> > +static void parse_allow_control_characters(const char *value)
> > +{
> > +	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
> > +	while (*value) {
> > +		if (skip_prefix_in_csv(value, "default", &value))
> > +			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
> > +		else if (skip_prefix_in_csv(value, "color", &value))
> > +			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
> > +		else if (skip_prefix_in_csv(value, "cursor", &value))
> > +			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
> > +		else if (skip_prefix_in_csv(value, "erase", &value))
> > +			allow_control_characters |= ALLOW_ANSI_ERASE;
> > +		else if (skip_prefix_in_csv(value, "true", &value))
> > +			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
> > +		else if (skip_prefix_in_csv(value, "false", &value))
> > +			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
> 
> Does it really make sense to also handle "true" and "false" here? I
> would expect that those values can only be passed standalone.

I was thinking that 1) it keeps the implementation more consistent, and 2)
it would allow for an "oops, let's restart this" type of approach, saying
`color,erase,false,color`.

Might be over-engineered, but the alternative would have to take care of
special-casing `true` and `false` in the following warning (because they
_are_ recognized, they just wouldn't be recognized inside a
comma-separated list).

> 
> > +		else
> > +			warning(_("unrecognized value for `sideband."
> > +				  "allowControlCharacters`: '%s'"), value);
> > +	}
> > +}
> 
> This could be simplified if we used e.g. `string_list_split()`. But on
> the other hand it avoids allocations, so that's a nice benefit.

The code also was a lot more verbose. I know, because that's what it
looked like before I changed it. :-)

Ciao,
Johannes

[PATCH v3 0/5] Sanitize sideband channel messages

[Johannes Schindelin via GitGitGadget]

Git's sideband channel passes server output directly to the client terminal
without sanitization. This includes progress messages, error output, and
diagnostics from remote hooks during clone, fetch, and push operations.

This creates an ANSI escape sequence injection vulnerability (CWE-150
[https://cwe.mitre.org/data/definitions/150.html]). A malicious or
compromised server can corrupt terminal state, obscure information, or
inject characters into the terminal's input buffer. The client has no
mechanism to distinguish between legitimate output and attack sequences.

This series fixes the vulnerability by sanitizing control characters in the
sideband output. ANSI color sequences (SGR codes) pass through by default,
since server-side hooks exist that use these for visibility (e.g.
https://github.com/kikeonline/githook-explode). By default, all other
control characters are rendered in caret notation (e.g., ESC becomes ^[).

Users who need different behavior get configuration options:
sideband.allowControlCharacters provides an escape hatch for environments
that require raw passthrough. The defaults are secure.

Note: This series applies cleanly on v2.47.3. Integrating this into newer
versions is a bit cumbersome; I pushed a version of the branch as rebased to
v2.53.0-rc0 here:
https://github.com/dscho/git/tree/refs/heads/sanitize-sideband-2.53.0-rc0

Changes since v2:

 * Added curly brackets around a single-line if clause.
 * Enclosed the values in the documentation within backticks.
 * Aligned the enum values for better readability.
 * Added support for sideband.<url>.allowControlCharacters (à la
   http.<url>.*) on top of sideband.allowControlCharacters.

Changes since v1:

 * Applied the suggestions by Phillip and brian.
 * Rebased onto v2.47.3.
 * Added more categories of ANSI Escape sequences that can be enabled (but
   that are off by default because they could be used to hide information).

Johannes Schindelin (5):
  sideband: mask control characters
  sideband: introduce an "escape hatch" to allow control characters
  sideband: do allow ANSI color sequences by default
  sideband: add options to allow more control sequences to be passed
    through
  sideband: offer to configure sanitizing on a per-URL basis

 Documentation/config.txt            |   2 +
 Documentation/config/sideband.txt   |  28 +++++
 sideband.c                          | 181 +++++++++++++++++++++++++++-
 sideband.h                          |  14 +++
 t/t5409-colorize-remote-messages.sh |  92 ++++++++++++++
 transport.c                         |   3 +
 6 files changed, 318 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/config/sideband.txt


base-commit: a52a24e03c8c711f1d5e252fba78f9276908129b
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1853/dscho/sanitize-sideband-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/1853

Range-diff vs v2:

 1:  8d70476559 ! 1:  e6b71af0ca sideband: mask control characters
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
      +{
      +	strbuf_grow(dest, n);
      +	for (; n && *src; src++, n--) {
     -+		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
     ++		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
      +			strbuf_addch(dest, *src);
     -+		else {
     ++		} else {
      +			strbuf_addch(dest, '^');
      +			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
      +		}
 2:  2615abd8c5 ! 2:  8f64d65844 sideband: introduce an "escape hatch" to allow control characters
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
      +
       	strbuf_grow(dest, n);
       	for (; n && *src; src++, n--) {
     - 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
     + 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
      
       ## t/t5409-colorize-remote-messages.sh ##
      @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'disallow (color) control sequences in sideband' '
 3:  44585ba1f4 ! 3:  44838acacc sideband: do allow ANSI color sequences by default
     @@ Documentation/config/sideband.txt
      +	this config setting to override this behavior:
      ++
      +--
     -+	default::
     -+	color::
     ++	`default`::
     ++	`color`::
      +		Allow ANSI color sequences, line feeds and horizontal tabs,
      +		but mask all other control characters. This is the default.
     -+	false::
     ++	`false`::
      +		Mask all control characters other than line feeds and
      +		horizontal tabs.
     -+	true::
     ++	`true`::
      +		Allow all control characters to be sent to the terminal.
      +--
      
     @@ sideband.c: static struct keyword_entry keywords[] = {
       
      -static int allow_control_characters;
      +static enum {
     -+	ALLOW_NO_CONTROL_CHARACTERS = 0,
     -+	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
     ++	ALLOW_NO_CONTROL_CHARACTERS  = 0,
     ++	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
      +	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
      +	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
      +} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, cons
       	}
      @@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
       	for (; n && *src; src++, n--) {
     - 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
     + 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
       			strbuf_addch(dest, *src);
     --		else {
     -+		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
     ++		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
      +			src += i;
      +			n -= i;
     -+		} else {
     + 		} else {
       			strbuf_addch(dest, '^');
       			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
     - 		}
      
       ## t/t5409-colorize-remote-messages.sh ##
      @@ t/t5409-colorize-remote-messages.sh: test_expect_success 'fallback to color.ui' '
 4:  fe109cd331 ! 4:  cc578465b9 sideband: add options to allow more control sequences to be passed through
     @@ Documentation/config/sideband.txt: sideband.allowControlCharacters::
      +	a comma-separated list of the following keywords):
       +
       --
     - 	default::
     - 	color::
     + 	`default`::
     + 	`color`::
       		Allow ANSI color sequences, line feeds and horizontal tabs,
       		but mask all other control characters. This is the default.
     -+	cursor::
     ++	`cursor:`:
      +		Allow control sequences that move the cursor. This is
      +		disabled by default.
     -+	erase::
     ++	`erase`::
      +		Allow control sequences that erase charactrs. This is
      +		disabled by default.
     - 	false::
     + 	`false`::
       		Mask all control characters other than line feeds and
       		horizontal tabs.
      
       ## sideband.c ##
      @@ sideband.c: static struct keyword_entry keywords[] = {
       static enum {
     - 	ALLOW_NO_CONTROL_CHARACTERS = 0,
     - 	ALLOW_ANSI_COLOR_SEQUENCES = 1<<0,
     -+	ALLOW_ANSI_CURSOR_MOVEMENTS = 1<<1,
     -+	ALLOW_ANSI_ERASE = 1<<2,
     + 	ALLOW_NO_CONTROL_CHARACTERS  = 0,
     + 	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
     ++	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
     ++	ALLOW_ANSI_ERASE             = 1<<2,
       	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
      -	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
      -} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
     @@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *sr
       	}
      @@ sideband.c: static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
       	for (; n && *src; src++, n--) {
     - 		if (!iscntrl(*src) || *src == '\t' || *src == '\n')
     + 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
       			strbuf_addch(dest, *src);
     --		else if ((i = handle_ansi_color_sequence(dest, src, n))) {
     -+		else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
     -+			 (i = handle_ansi_sequence(dest, src, n))) {
     +-		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
     ++		} else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
     ++			   (i = handle_ansi_sequence(dest, src, n))) {
       			src += i;
       			n -= i;
       		} else {
 -:  ---------- > 5:  f2eb0a758c sideband: offer to configure sanitizing on a per-URL basis

-- 
gitgitgadget

[PATCH v3 1/5] sideband: mask control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The output of `git clone` is a vital component for understanding what
has happened when things go wrong. However, these logs are partially
under the control of the remote server (via the "sideband", which
typically contains what the remote `git pack-objects` process sends to
`stderr`), and is currently not sanitized by Git.

This makes Git susceptible to ANSI escape sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
attackers to corrupt terminal state, to hide information, and even to
insert characters into the input buffer (i.e. as if the user had typed
those characters).

To plug this vulnerability, disallow any control character in the
sideband, replacing them instead with the common `^<letter/symbol>`
(e.g. `^[` for `\x1b`, `^A` for `\x01`).

There is likely a need for more fine-grained controls instead of using a
"heavy hammer" like this, which will be introduced subsequently.

Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 sideband.c                          | 17 +++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 12 ++++++++++++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/sideband.c b/sideband.c
index 02805573fa..3c74f3bdb7 100644
--- a/sideband.c
+++ b/sideband.c
@@ -65,6 +65,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
+{
+	strbuf_grow(dest, n);
+	for (; n && *src; src++, n--) {
+		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
+			strbuf_addch(dest, *src);
+		} else {
+			strbuf_addch(dest, '^');
+			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
+		}
+	}
+}
+
 /*
  * Optionally highlight one keyword in remote output if it appears at the start
  * of the line. This should be called for a single line only, which is
@@ -80,7 +93,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 	int i;
 
 	if (!want_color_stderr(use_sideband_colors())) {
-		strbuf_add(dest, src, n);
+		strbuf_add_sanitized(dest, src, n);
 		return;
 	}
 
@@ -113,7 +126,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 		}
 	}
 
-	strbuf_add(dest, src, n);
+	strbuf_add_sanitized(dest, src, n);
 }
 
 
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 516b22fd96..f4712f4161 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -99,4 +99,16 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+test_expect_success 'disallow (color) control sequences in sideband' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep ! RED decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH v3 2/5] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding commit fixed the vulnerability whereas sideband messages
(that are under the control of the remote server) could contain ANSI
escape sequences that would be sent to the terminal verbatim.

However, this fix may not be desirable under all circumstances, e.g.
when remote servers deliberately add coloring to their messages to
increase their urgency.

To help with those use cases, give users a way to opt-out of the
protections: `sideband.allowControlCharacters`.

Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config.txt            |  2 ++
 Documentation/config/sideband.txt   |  5 +++++
 sideband.c                          | 10 ++++++++++
 t/t5409-colorize-remote-messages.sh |  8 +++++++-
 4 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/config/sideband.txt

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8c0b3ed807..48870bb588 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -522,6 +522,8 @@ include::config/sequencer.txt[]
 
 include::config/showbranch.txt[]
 
+include::config/sideband.txt[]
+
 include::config/sparse.txt[]
 
 include::config/splitindex.txt[]
diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
new file mode 100644
index 0000000000..3fb5045cd7
--- /dev/null
+++ b/Documentation/config/sideband.txt
@@ -0,0 +1,5 @@
+sideband.allowControlCharacters::
+	By default, control characters that are delivered via the sideband
+	are masked, to prevent potentially unwanted ANSI escape sequences
+	from being sent to the terminal. Use this config setting to override
+	this behavior.
diff --git a/sideband.c b/sideband.c
index 3c74f3bdb7..1499587ff6 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,6 +25,8 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
+static int allow_control_characters;
+
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
 {
@@ -38,6 +40,9 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
+	git_config_get_bool("sideband.allowcontrolcharacters",
+			    &allow_control_characters);
+
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
 	else if (!git_config_get_string_tmp("color.ui", &value))
@@ -67,6 +72,11 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
+	if (allow_control_characters) {
+		strbuf_add(dest, src, n);
+		return;
+	}
+
 	strbuf_grow(dest, n);
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index f4712f4161..e8067df591 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -106,9 +106,15 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
+
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep ! RED decoded
+	test_grep ! RED decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep RED decoded
 '
 
 test_done
-- 
gitgitgadget

[PATCH v3 3/5] sideband: do allow ANSI color sequences by default

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding two commits introduced special handling of the sideband
channel to neutralize ANSI escape sequences before sending the payload
to the terminal, and `sideband.allowControlCharacters` to override that
behavior.

However, as reported by brian m. carlson, some `pre-receive` hooks that
are actively used in practice want to color their messages and therefore
rely on the fact that Git passes them through to the terminal, even
though they have no way to determine whether the receiving side can
actually handle Escape sequences (think e.g. about the practice
recommended by Git that third-party applications wishing to use Git
functionality parse the output of Git commands).

In contrast to other ANSI escape sequences, it is highly unlikely that
coloring sequences can be essential tools in attack vectors that mislead
Git users e.g. by hiding crucial information.

Therefore we can have both: Continue to allow ANSI coloring sequences to
be passed to the terminal by default, and neutralize all other ANSI
Escape sequences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   | 18 ++++++--
 sideband.c                          | 66 +++++++++++++++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 16 ++++++-
 3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 3fb5045cd7..b55c73726f 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -1,5 +1,17 @@
 sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
-	are masked, to prevent potentially unwanted ANSI escape sequences
-	from being sent to the terminal. Use this config setting to override
-	this behavior.
+	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal. Use
+	this config setting to override this behavior:
++
+--
+	`default`::
+	`color`::
+		Allow ANSI color sequences, line feeds and horizontal tabs,
+		but mask all other control characters. This is the default.
+	`false`::
+		Mask all control characters other than line feeds and
+		horizontal tabs.
+	`true`::
+		Allow all control characters to be sent to the terminal.
+--
diff --git a/sideband.c b/sideband.c
index 1499587ff6..f4bcdcaf9b 100644
--- a/sideband.c
+++ b/sideband.c
@@ -25,7 +25,12 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
-static int allow_control_characters;
+static enum {
+	ALLOW_NO_CONTROL_CHARACTERS  = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
+} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -40,8 +45,26 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	git_config_get_bool("sideband.allowcontrolcharacters",
-			    &allow_control_characters);
+	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
+	case 0: /* Boolean value */
+		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
+			ALLOW_NO_CONTROL_CHARACTERS;
+		break;
+	case -1: /* non-Boolean value */
+		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
+					      &value))
+			; /* huh? `get_maybe_bool()` returned -1 */
+		else if (!strcmp(value, "default"))
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (!strcmp(value, "color"))
+			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+		break;
+	default:
+		break; /* not configured */
+	}
 
 	if (!git_config_get_string_tmp(key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
@@ -70,9 +93,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+{
+	int i;
+
+	/*
+	 * Valid ANSI color sequences are of the form
+	 *
+	 * ESC [ [<n> [; <n>]*] m
+	 *
+	 * These are part of the Select Graphic Rendition sequences which
+	 * contain more than just color sequences, for more details see
+	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 */
+
+	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
+	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+		return 0;
+
+	for (i = 2; i < n; i++) {
+		if (src[i] == 'm') {
+			strbuf_add(dest, src, i + 1);
+			return i;
+		}
+		if (!isdigit(src[i]) && src[i] != ';')
+			break;
+	}
+
+	return 0;
+}
+
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
-	if (allow_control_characters) {
+	int i;
+
+	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -81,6 +136,9 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
+		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+			src += i;
+			n -= i;
 		} else {
 			strbuf_addch(dest, '^');
 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index e8067df591..f34977b332 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -101,7 +101,7 @@ test_expect_success 'fallback to color.ui' '
 
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
-	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
@@ -109,12 +109,24 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
+	test_grep RED decoded &&
+	test_grep "\\^G" stderr &&
+	tr -dc "\\007" <stderr >actual &&
+	test_must_be_empty actual &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=false \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
 	test_grep ! RED decoded &&
+	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
 	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep RED decoded
+	test_grep RED decoded &&
+	tr -dc "\\007" <stderr >actual &&
+	test_file_not_empty actual
 '
 
 test_done
-- 
gitgitgadget

[PATCH v3 4/5] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Even though control sequences that erase characters are quite juicy for
attack scenarios, where attackers are eager to hide traces of suspicious
activities, during the review of the side band sanitizing patch series
concerns were raised that there might be some legimitate scenarios where
Git server's `pre-receive` hooks use those sequences in a benign way.

Control sequences to move the cursor can likewise be used to hide tracks
by overwriting characters, and have been equally pointed out as having
legitimate users.

Let's add options to let users opt into passing through those ANSI
Escape sequences: `sideband.allowControlCharacters` now supports also
`cursor` and `erase`, and it parses the value as a comma-separated list.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   |  9 ++-
 sideband.c                          | 91 ++++++++++++++++++++++++-----
 t/t5409-colorize-remote-messages.sh | 38 ++++++++++++
 3 files changed, 123 insertions(+), 15 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index b55c73726f..2bf0426284 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -2,13 +2,20 @@ sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
 	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior:
+	this config setting to override this behavior (the value can be
+	a comma-separated list of the following keywords):
 +
 --
 	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
+	`cursor:`:
+		Allow control sequences that move the cursor. This is
+		disabled by default.
+	`erase`::
+		Allow control sequences that erase charactrs. This is
+		disabled by default.
 	`false`::
 		Mask all control characters other than line feeds and
 		horizontal tabs.
diff --git a/sideband.c b/sideband.c
index f4bcdcaf9b..a8568b8b64 100644
--- a/sideband.c
+++ b/sideband.c
@@ -28,9 +28,43 @@ static struct keyword_entry keywords[] = {
 static enum {
 	ALLOW_NO_CONTROL_CHARACTERS  = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
+	ALLOW_ANSI_ERASE             = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
+} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+
+static inline int skip_prefix_in_csv(const char *value, const char *prefix,
+				     const char **out)
+{
+	if (!skip_prefix(value, prefix, &value) ||
+	    (*value && *value != ','))
+		return 0;
+	*out = value + !!*value;
+	return 1;
+}
+
+static void parse_allow_control_characters(const char *value)
+{
+	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+	while (*value) {
+		if (skip_prefix_in_csv(value, "default", &value))
+			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "color", &value))
+			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "cursor", &value))
+			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
+		else if (skip_prefix_in_csv(value, "erase", &value))
+			allow_control_characters |= ALLOW_ANSI_ERASE;
+		else if (skip_prefix_in_csv(value, "true", &value))
+			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		else if (skip_prefix_in_csv(value, "false", &value))
+			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+	}
+}
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static int use_sideband_colors(void)
@@ -54,13 +88,8 @@ static int use_sideband_colors(void)
 		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
 					      &value))
 			; /* huh? `get_maybe_bool()` returned -1 */
-		else if (!strcmp(value, "default"))
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (!strcmp(value, "color"))
-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			parse_allow_control_characters(value);
 		break;
 	default:
 		break; /* not configured */
@@ -93,7 +122,7 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
@@ -105,14 +134,47 @@ static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
 	 * These are part of the Select Graphic Rendition sequences which
 	 * contain more than just color sequences, for more details see
 	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 *
+	 * The cursor movement sequences are:
+	 *
+	 * ESC [ n A - Cursor up n lines (CUU)
+	 * ESC [ n B - Cursor down n lines (CUD)
+	 * ESC [ n C - Cursor forward n columns (CUF)
+	 * ESC [ n D - Cursor back n columns (CUB)
+	 * ESC [ n E - Cursor next line, beginning (CNL)
+	 * ESC [ n F - Cursor previous line, beginning (CPL)
+	 * ESC [ n G - Cursor to column n (CHA)
+	 * ESC [ n ; m H - Cursor position (row n, col m) (CUP)
+	 * ESC [ n ; m f - Same as H (HVP)
+	 *
+	 * The sequences to erase characters are:
+	 *
+	 *
+	 * ESC [ 0 J - Clear from cursor to end of screen (ED)
+	 * ESC [ 1 J - Clear from cursor to beginning of screen (ED)
+	 * ESC [ 2 J - Clear entire screen (ED)
+	 * ESC [ 3 J - Clear entire screen + scrollback (ED) - xterm extension
+	 * ESC [ 0 K - Clear from cursor to end of line (EL)
+	 * ESC [ 1 K - Clear from cursor to beginning of line (EL)
+	 * ESC [ 2 K - Clear entire line (EL)
+	 * ESC [ n M - Delete n lines (DL)
+	 * ESC [ n P - Delete n characters (DCH)
+	 * ESC [ n X - Erase n characters (ECH)
+	 *
+	 * For a comprehensive list of common ANSI Escape sequences, see
+	 * https://www.xfree86.org/current/ctlseqs.html
 	 */
 
-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+	if (n < 3 || src[0] != '\x1b' || src[1] != '[')
 		return 0;
 
 	for (i = 2; i < n; i++) {
-		if (src[i] == 'm') {
+		if (((allow_control_characters & ALLOW_ANSI_COLOR_SEQUENCES) &&
+		     src[i] == 'm') ||
+		    ((allow_control_characters & ALLOW_ANSI_CURSOR_MOVEMENTS) &&
+		     strchr("ABCDEFGHf", src[i])) ||
+		    ((allow_control_characters & ALLOW_ANSI_ERASE) &&
+		     strchr("JKMPX", src[i]))) {
 			strbuf_add(dest, src, i + 1);
 			return i;
 		}
@@ -127,7 +189,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
+	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -136,7 +198,8 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
-		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+		} else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
+			   (i = handle_ansi_sequence(dest, src, n))) {
 			src += i;
 			n -= i;
 		} else {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index f34977b332..c3e4e14362 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -129,4 +129,42 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_file_not_empty actual
 '
 
+test_decode_csi() {
+	awk '{
+		while (match($0, /\033/) != 0) {
+			printf "%sCSI ", substr($0, 1, RSTART-1);
+			$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
+		}
+		print
+	}'
+}
+
+test_expect_success 'control sequences in sideband allowed by default' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit-at-least &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep ! "CSI \\[G" decoded &&
+	test_grep "\\^\\[?25l" decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=erase,cursor,color \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "RED" decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep "CSI \\[G" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded &&
+	test_grep ! "\\^\\[\\[G" decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH v3 5/5] sideband: offer to configure sanitizing on a per-URL basis

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The main objection against sanitizing the sideband that was raised
during the review of the sideband sanitizing patches, first on the
git-security mailing list, then on the public mailing list, was that
there are some setups where server-side `pre-receive` hooks want to
error out, giving colorful messages to the users on the client side (if
they are not redirecting the output into a file, that is).

To avoid breaking such setups, the default chosen by the sideband
sanitizing patches is to pass through ANSI color sequences.

Still, there might be some use case out there where that is not enough.
Therefore the `sideband.allowControlCharacters` config setting allows
for configuring  levels of sanitizing.

As Junio Hamano pointed out, to keep users safe by default, we need to
be able to scope this to some servers because while a user may trust
their company's Git server, the same might not apply to other Git
servers.

To allow for this, let's imitate the way `http.<url>.*` offers
to scope config settings to certain URLs, by letting users
override the `sideband.allowControlCharacters` setting via
`sideband.<url>.allowControlCharacters`.

Suggested-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.txt   |  4 ++
 sideband.c                          | 81 ++++++++++++++++++++---------
 sideband.h                          | 14 +++++
 t/t5409-colorize-remote-messages.sh | 24 +++++++++
 transport.c                         |  3 ++
 5 files changed, 102 insertions(+), 24 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 2bf0426284..32088bbf2f 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -22,3 +22,7 @@ sideband.allowControlCharacters::
 	`true`::
 		Allow all control characters to be sent to the terminal.
 --
+
+sideband.<url>.*::
+	Apply the `sideband.*` option selectively to specific URLs. The
+	same URL matching logic applies as for `http.<url>.*` settings.
diff --git a/sideband.c b/sideband.c
index a8568b8b64..a8cd142cd7 100644
--- a/sideband.c
+++ b/sideband.c
@@ -9,6 +9,7 @@
 #include "help.h"
 #include "pkt-line.h"
 #include "write-or-die.h"
+#include "urlmatch.h"
 
 struct keyword_entry {
 	/*
@@ -26,13 +27,14 @@ static struct keyword_entry keywords[] = {
 };
 
 static enum {
-	ALLOW_NO_CONTROL_CHARACTERS  = 0,
-	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
-	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
-	ALLOW_ANSI_ERASE             = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
-} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
+	ALLOW_NO_CONTROL_CHARACTERS   = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
+	ALLOW_ANSI_ERASE              = 1<<2,
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+} allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 				     const char **out)
@@ -44,8 +46,19 @@ static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 	return 1;
 }
 
-static void parse_allow_control_characters(const char *value)
+int sideband_allow_control_characters_config(const char *var, const char *value)
 {
+	switch (git_parse_maybe_bool(value)) {
+	case 0:
+		allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		return 0;
+	case 1:
+		allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		return 0;
+	default:
+		break;
+	}
+
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
 		if (skip_prefix_in_csv(value, "default", &value))
@@ -61,9 +74,37 @@ static void parse_allow_control_characters(const char *value)
 		else if (skip_prefix_in_csv(value, "false", &value))
 			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			warning(_("unrecognized value for '%s': '%s'"), var, value);
 	}
+	return 0;
+}
+
+static int sideband_config_callback(const char *var, const char *value,
+				    const struct config_context *ctx UNUSED,
+				    void *data UNUSED)
+{
+	if (!strcmp(var, "sideband.allowcontrolcharacters"))
+		return sideband_allow_control_characters_config(var, value);
+
+	return 0;
+}
+
+void sideband_apply_url_config(const char *url)
+{
+	struct urlmatch_config config = URLMATCH_CONFIG_INIT;
+	char *normalized_url;
+
+	if (!url)
+		BUG("must not call sideband_apply_url_config(NULL)");
+
+	config.section = "sideband";
+	config.collect_fn = sideband_config_callback;
+
+	normalized_url = url_normalize(url, &config.url);
+	git_config(urlmatch_config_entry, &config);
+	free(normalized_url);
+	string_list_clear(&config.vars, 1);
+	urlmatch_config_release(&config);
 }
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
@@ -79,20 +120,12 @@ static int use_sideband_colors(void)
 	if (use_sideband_colors_cached >= 0)
 		return use_sideband_colors_cached;
 
-	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
-	case 0: /* Boolean value */
-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
-			ALLOW_NO_CONTROL_CHARACTERS;
-		break;
-	case -1: /* non-Boolean value */
-		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
-					      &value))
-			; /* huh? `get_maybe_bool()` returned -1 */
-		else
-			parse_allow_control_characters(value);
-		break;
-	default:
-		break; /* not configured */
+	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
+		if (!git_config_get_value("sideband.allowcontrolcharacters", &value))
+			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
+
+		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
 	}
 
 	if (!git_config_get_string_tmp(key, &value))
diff --git a/sideband.h b/sideband.h
index 5a25331be5..d15fa4015f 100644
--- a/sideband.h
+++ b/sideband.h
@@ -30,4 +30,18 @@ int demultiplex_sideband(const char *me, int status,
 
 void send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
 
+/*
+ * Apply sideband configuration for the given URL. This should be called
+ * when a transport is created to allow URL-specific configuration of
+ * sideband behavior (e.g., sideband.<url>.allowControlCharacters).
+ */
+void sideband_apply_url_config(const char *url);
+
+/*
+ * Parse and set the sideband allow control characters configuration.
+ * The var parameter should be the key name (without section prefix).
+ * Returns 0 if the variable was recognized and handled, non-zero otherwise.
+ */
+int sideband_allow_control_characters_config(const char *var, const char *value);
+
 #endif
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index c3e4e14362..1d039cbdaf 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -167,4 +167,28 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_grep ! "\\^\\[\\[G" decoded
 '
 
+test_expect_success 'allow all control sequences for a specific URL' '
+	write_script .git/eraser <<-\EOF &&
+	printf "error: Ohai!\\r\\033[K" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./eraser &&
+	test_commit one-more-please &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep "\\^\\[\\[K" decoded &&
+
+	rm -rf throw-away &&
+	git -c "sideband.file://.allowControlCharacters=true" \
+		clone --no-local "file://$PWD" throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded
+'
+
 test_done
diff --git a/transport.c b/transport.c
index 1098bbd60e..e19536c9c6 100644
--- a/transport.c
+++ b/transport.c
@@ -28,6 +28,7 @@
 #include "object-name.h"
 #include "color.h"
 #include "bundle-uri.h"
+#include "sideband.h"
 
 static int transport_use_color = -1;
 static char transport_colors[][COLOR_MAXLEN] = {
@@ -1210,6 +1211,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1];
 
+	sideband_apply_url_config(ret->url);
+
 	return ret;
 }
 
-- 
gitgitgadget

Re: [PATCH v3 0/5] Sanitize sideband channel messages

[Johannes Schindelin]

Hi,

On Fri, 16 Jan 2026, Johannes Schindelin via GitGitGadget wrote:

> Note: This series applies cleanly on v2.47.3. Integrating this into newer
> versions is a bit cumbersome; I pushed a version of the branch as rebased to
> v2.53.0-rc0 here:
> https://github.com/dscho/git/tree/refs/heads/sanitize-sideband-2.53.0-rc0

Here is the range-diff:

1:  e6b71af0cad = 1:  757c859add0 sideband: mask control characters
2:  8f64d658447 ! 2:  28c9fa7e205 sideband: introduce an "escape hatch" to allow control characters
    @@ Commit message
         Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
         Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     
    - ## Documentation/config.txt ##
    -@@ Documentation/config.txt: include::config/sequencer.txt[]
    + ## Documentation/config.adoc ##
    +@@ Documentation/config.adoc: include::config/sequencer.adoc[]
      
    - include::config/showbranch.txt[]
    + include::config/showbranch.adoc[]
      
    -+include::config/sideband.txt[]
    ++include::config/sideband.adoc[]
     +
    - include::config/sparse.txt[]
    + include::config/sparse.adoc[]
      
    - include::config/splitindex.txt[]
    + include::config/splitindex.adoc[]
     
    - ## Documentation/config/sideband.txt (new) ##
    + ## Documentation/config/sideband.adoc (new) ##
     @@
     +sideband.allowControlCharacters::
     +	By default, control characters that are delivered via the sideband
    @@ sideband.c: static struct keyword_entry keywords[] = {
     +static int allow_control_characters;
     +
      /* Returns a color setting (GIT_COLOR_NEVER, etc). */
    - static int use_sideband_colors(void)
    + static enum git_colorbool use_sideband_colors(void)
      {
    -@@ sideband.c: static int use_sideband_colors(void)
    - 	if (use_sideband_colors_cached >= 0)
    +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
    + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
      		return use_sideband_colors_cached;
      
    -+	git_config_get_bool("sideband.allowcontrolcharacters",
    ++	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
     +			    &allow_control_characters);
     +
    - 	if (!git_config_get_string_tmp(key, &value))
    + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
      		use_sideband_colors_cached = git_config_colorbool(key, value);
    - 	else if (!git_config_get_string_tmp("color.ui", &value))
    + 	else if (!repo_config_get_string_tmp(the_repository, "color.ui", &value))
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref
      
      static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
3:  44838acaccc ! 3:  58a4f78783b sideband: do allow ANSI color sequences by default
    @@ Commit message
     
         Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     
    - ## Documentation/config/sideband.txt ##
    + ## Documentation/config/sideband.adoc ##
     @@
      sideband.allowControlCharacters::
      	By default, control characters that are delivered via the sideband
    @@ sideband.c: static struct keyword_entry keywords[] = {
     +} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
      
      /* Returns a color setting (GIT_COLOR_NEVER, etc). */
    - static int use_sideband_colors(void)
    -@@ sideband.c: static int use_sideband_colors(void)
    - 	if (use_sideband_colors_cached >= 0)
    + static enum git_colorbool use_sideband_colors(void)
    +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
    + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
      		return use_sideband_colors_cached;
      
    --	git_config_get_bool("sideband.allowcontrolcharacters",
    +-	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
     -			    &allow_control_characters);
    -+	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
    ++	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
     +	case 0: /* Boolean value */
     +		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
     +			ALLOW_NO_CONTROL_CHARACTERS;
     +		break;
     +	case -1: /* non-Boolean value */
    -+		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
    ++		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
     +					      &value))
     +			; /* huh? `get_maybe_bool()` returned -1 */
     +		else if (!strcmp(value, "default"))
    @@ sideband.c: static int use_sideband_colors(void)
     +		break; /* not configured */
     +	}
      
    - 	if (!git_config_get_string_tmp(key, &value))
    + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
      		use_sideband_colors_cached = git_config_colorbool(key, value);
     @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref
      		list_config_item(list, prefix, keywords[i].keyword);
4:  cc578465b9c ! 4:  24708d83075 sideband: add options to allow more control sequences to be passed through
    @@ Commit message
     
         Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     
    - ## Documentation/config/sideband.txt ##
    -@@ Documentation/config/sideband.txt: sideband.allowControlCharacters::
    + ## Documentation/config/sideband.adoc ##
    +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
      	By default, control characters that are delivered via the sideband
      	are masked, except ANSI color sequences. This prevents potentially
      	unwanted ANSI escape sequences from being sent to the terminal. Use
    @@ sideband.c: static struct keyword_entry keywords[] = {
     +}
      
      /* Returns a color setting (GIT_COLOR_NEVER, etc). */
    - static int use_sideband_colors(void)
    -@@ sideband.c: static int use_sideband_colors(void)
    - 		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
    + static enum git_colorbool use_sideband_colors(void)
    +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
    + 		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
      					      &value))
      			; /* huh? `get_maybe_bool()` returned -1 */
     -		else if (!strcmp(value, "default"))
5:  f2eb0a758ce ! 5:  4db96901d02 sideband: offer to configure sanitizing on a per-URL basis
    @@ Commit message
         Suggested-by: Junio Hamano <gitster@pobox.com>
         Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
     
    - ## Documentation/config/sideband.txt ##
    -@@ Documentation/config/sideband.txt: sideband.allowControlCharacters::
    + ## Documentation/config/sideband.adoc ##
    +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
      	`true`::
      		Allow all control characters to be sent to the terminal.
      --
    @@ sideband.c: static void parse_allow_control_characters(const char *value)
     +	config.collect_fn = sideband_config_callback;
     +
     +	normalized_url = url_normalize(url, &config.url);
    -+	git_config(urlmatch_config_entry, &config);
    ++	repo_config(the_repository, urlmatch_config_entry, &config);
     +	free(normalized_url);
     +	string_list_clear(&config.vars, 1);
     +	urlmatch_config_release(&config);
      }
      
      /* Returns a color setting (GIT_COLOR_NEVER, etc). */
    -@@ sideband.c: static int use_sideband_colors(void)
    - 	if (use_sideband_colors_cached >= 0)
    +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
    + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
      		return use_sideband_colors_cached;
      
    --	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
    +-	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
     -	case 0: /* Boolean value */
     -		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
     -			ALLOW_NO_CONTROL_CHARACTERS;
     -		break;
     -	case -1: /* non-Boolean value */
    --		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
    +-		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
     -					      &value))
     -			; /* huh? `get_maybe_bool()` returned -1 */
     -		else
    @@ sideband.c: static int use_sideband_colors(void)
     -	default:
     -		break; /* not configured */
     +	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
    -+		if (!git_config_get_value("sideband.allowcontrolcharacters", &value))
    ++		if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value))
     +			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
     +
     +		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
     +			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
      	}
      
    - 	if (!git_config_get_string_tmp(key, &value))
    + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
     
      ## sideband.h ##
     @@ sideband.h: int demultiplex_sideband(const char *me, int status,
    @@ transport.c
      #include "bundle-uri.h"
     +#include "sideband.h"
      
    - static int transport_use_color = -1;
    + static enum git_colorbool transport_use_color = GIT_COLOR_UNKNOWN;
      static char transport_colors[][COLOR_MAXLEN] = {
     @@ transport.c: struct transport *transport_get(struct remote *remote, const char *url)
      
    - 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1];
    + 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1_LEGACY];
      
     +	sideband_apply_url_config(ret->url);
     +

Ciao,
Johannes

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Patrick Steinhardt]

On Fri, Jan 16, 2026 at 07:21:04AM -0800, Junio C Hamano wrote:
> Ondrej Pohorelsky <opohorel@redhat.com> writes:
> 
> > Hi, I just want to weight in from the downstream maintainer POV.
> > We've been carrying the patches Johannes has created in Fedora, CentOS
> > and RHEL for at least half a year now.
> > The only change I did is to make the new behavior opt-in by default
> > and give the RHEL customers a release note explaining it.
> 
> Thanks for your great input.  FWIW, I do not think anybody around
> here is against "opt-in with a note" approach at all.
> 
> > I think the patches proposed are making sense, and they should be
> > merged. Even having them as opt-in is better than not having them
> > merged at all.
> 
> I do not think anybody disagrees with this sentiment.  Back when the
> patches originally was discussed on the public list here, nobody was
> against adding it as an _optional_ feature to filter some byte
> sequences out of the end-user's data stream, and the review comments
> that led to the topic marked to be "expecting a reroll", if I recall
> correctly, were all about "why would we make this on by default?"
> Peff's message that reignited the topic this time around is also
> about the same.
> 
> We are still hearing from Dscho that he cannot think of a scenario
> where making this mandatory with opt-out would break existing
> legitimate setup people may have (I am paraphrasing [*]), but I
> think that is aiming in the wrong direction.  It does not matter if
> you consider the approach your users take is "broken by design"; as
> long as it works for them in their (limited) settings, it is a valid
> arrangement to send arbitrary byte sequence over the sideband even
> it happens to include ANSI escapes and other "curiosities".  We have
> in no position to unilaterally break them, telling them that we left
> a way open for them to disable.  That is not how to deliver features.

I think what I strongly disagree with is that this is considered to be a
feature. I myself don't consider this to be a feature though, but rather
a security fix for a bug that can lead to arbitrary code execution on
the client-side, for example via title bar injection.

It's not the first time that we change existing behaviour in a backwards
incompatible way because of a newly discovered attack vector. So I have
to wonder what's so different about this particular case here.

Patrick

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]

On 2026-01-19 at 07:20:41, Patrick Steinhardt wrote:
> I think what I strongly disagree with is that this is considered to be a
> feature. I myself don't consider this to be a feature though, but rather
> a security fix for a bug that can lead to arbitrary code execution on
> the client-side, for example via title bar injection.

I don't agree with that.  Nobody still enables the functionality in a
terminal that allows title bar injection.  And, as I've pointed out,
even connecting to an SSH remote allows exactly the same behaviour as
this patch seems to try to fix, so there is no actual security benefit
to enabling these patches there.  Defaulting this series to on is like
closing the barn door to prevent the horse from getting out when there's
a giant hole in the barn wall.

It should be pointed out that, in general, simply using SSH to connect
to an untrusted remote system or using `cat` on an untrusted file can do
exactly the same thing as this series tries to prevent by sending
arbitrary terminal codes to the terminal.  Nobody has sent patches for
SSH to make it filter out terminal sequences.

I have also found pre-receive hooks on GitHub that will be broken by
these changes.  Just because Dscho has not seen them doesn't mean that
they don't exist and many users who are not on Windows do not run the
latest Git (they run what's provided by their distro or vendor), so they
won't notice that things are broken until we've shipped the feature
being on by default.

I'm not opposed to adding support for this as an opt-in feature for
those people that want it, though, and I think that's the right path for
including it.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[D. Ben Knoble]

Forgive my self-insertion to this series…

On Mon, Jan 19, 2026 at 5:16 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2026-01-19 at 07:20:41, Patrick Steinhardt wrote:
> > I think what I strongly disagree with is that this is considered to be a
> > feature. I myself don't consider this to be a feature though, but rather
> > a security fix for a bug that can lead to arbitrary code execution on
> > the client-side, for example via title bar injection.
>
> I don't agree with that.  Nobody still enables the functionality in a
> terminal that allows title bar injection.  And, as I've pointed out,
> even connecting to an SSH remote allows exactly the same behaviour as
> this patch seems to try to fix, so there is no actual security benefit
> to enabling these patches there.  Defaulting this series to on is like
> closing the barn door to prevent the horse from getting out when there's
> a giant hole in the barn wall.
>
> It should be pointed out that, in general, simply using SSH to connect
> to an untrusted remote system or using `cat` on an untrusted file can do
> exactly the same thing as this series tries to prevent by sending
> arbitrary terminal codes to the terminal.  Nobody has sent patches for
> SSH to make it filter out terminal sequences.

It sounds like you say "There are other holes, so it doesn't make
sense to try to close this one." I don't think you mean or believe
that, though I don't want to put words in your mouth. I just don't
find that a particularly compelling argument, especially with typical
practice of the "swiss cheese" model of security.

> I have also found pre-receive hooks on GitHub that will be broken by
> these changes.  Just because Dscho has not seen them doesn't mean that
> they don't exist and many users who are not on Windows do not run the
> latest Git (they run what's provided by their distro or vendor), so they
> won't notice that things are broken until we've shipped the feature
> being on by default.
>
> I'm not opposed to adding support for this as an opt-in feature for
> those people that want it, though, and I think that's the right path for
> including it.
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA


Cordially,
-- 
D. Ben Knoble

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I'm not opposed to adding support for this as an opt-in feature for
> those people that want it, though, and I think that's the right path for
> including it.

Yup.  I am hoping that there are no folks who think that forcing
this filtering on everybody is so important that it must not go in
unless it is enabled by default.

I however wonder if we need two different levels defaults, depending
on where the user is going, to make it less painful to configure
things.  I would imagine the remotes one would interact with fall
into two quite different categories.

 - The ones that you talk with every day, essential in your work,
   would be something you would have to be able to trust and if
   these trusted people want to give you a bit more colorful output
   from their hooks, you shouldn't have to manually configure "I
   accept colors from them", for example.

 - There are others that you will visit for the first time as you
   try to discover new good things.  These you may want to be extra
   cautious about than the familiar remotes in your everyday work.

Perhaps "git clone $URL" should filter the terminal output by
default, but once inside the resulting repository, "git push" and
"git pull" from the established remote that is used by default when
you do not say whom to talk to, our default can be more lenient, or
something?

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Jeff King]

On Tue, Jan 20, 2026 at 09:05:27AM -0800, Junio C Hamano wrote:

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > I'm not opposed to adding support for this as an opt-in feature for
> > those people that want it, though, and I think that's the right path for
> > including it.
> 
> Yup.  I am hoping that there are no folks who think that forcing
> this filtering on everybody is so important that it must not go in
> unless it is enabled by default.
> 
> I however wonder if we need two different levels defaults, depending
> on where the user is going, to make it less painful to configure
> things.  I would imagine the remotes one would interact with fall
> into two quite different categories.
> 
>  - The ones that you talk with every day, essential in your work,
>    would be something you would have to be able to trust and if
>    these trusted people want to give you a bit more colorful output
>    from their hooks, you shouldn't have to manually configure "I
>    accept colors from them", for example.
> 
>  - There are others that you will visit for the first time as you
>    try to discover new good things.  These you may want to be extra
>    cautious about than the familiar remotes in your everyday work.
> 
> Perhaps "git clone $URL" should filter the terminal output by
> default, but once inside the resulting repository, "git push" and
> "git pull" from the established remote that is used by default when
> you do not say whom to talk to, our default can be more lenient, or
> something?

I hesitate to suggest this, but: we have a similar distinction already
for protocol selection, where GIT_PROTOCOL_FROM_USER tells us whether
the URL came directly from the user, or if we were directed there as
part of an untrusted automated process (like a .gitmodules file).

We use that to disallow file:// from .gitmodules without breaking "git
clone file://" on the command line.

So we _could_ use that as a signal here, to suggest that servers you
feed on the command line (including remotes you've defined) are more
trusted than ones that you may have been redirected to from a possibly
malicious .gitmodules file.

But I say "hesitate" because:

  1. This is a convoluted scheme making heuristic assumptions about
     trust. It was a not-so-bad way of compromising on the file://
     thing, but it may not be worth the complications here.

  2. The trust boundaries aren't quite the same anyway. If I feed
     "https://evil.example.com" to Git manually, I can verify that
     "https" is the URL and that is OK to use the HTTP protocol. But it
     doesn't say anything about whether I trust example.com to write to
     my terminal.

So maybe a dumb direction, but just thinking out loud.

-Peff

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I hesitate to suggest this, but: we have a similar distinction already
> for protocol selection, where GIT_PROTOCOL_FROM_USER tells us whether
> the URL came directly from the user, or if we were directed there as
> part of an untrusted automated process (like a .gitmodules file).
>
> We use that to disallow file:// from .gitmodules without breaking "git
> clone file://" on the command line.
>
> So we _could_ use that as a signal here, to suggest that servers you
> feed on the command line (including remotes you've defined) are more
> trusted than ones that you may have been redirected to from a possibly
> malicious .gitmodules file.
>
> But I say "hesitate" because:
>
>   1. This is a convoluted scheme making heuristic assumptions about
>      trust. It was a not-so-bad way of compromising on the file://
>      thing, but it may not be worth the complications here.
>
>   2. The trust boundaries aren't quite the same anyway. If I feed
>      "https://evil.example.com" to Git manually, I can verify that
>      "https" is the URL and that is OK to use the HTTP protocol. But it
>      doesn't say anything about whether I trust example.com to write to
>      my terminal.
>
> So maybe a dumb direction, but just thinking out loud.

Yeah, I think #2 makes it unworkable for this purpose.  When
somebody you met recently at a party and you not yet know how much
to trust told you "You may be interested in this nifty add-on I have
in my repository at https://example.com/nifty.git", you may want to
clone it only to peek at it first without trusting it.  So automated
or manually fed from the command line, I'd say the destination where
"git clone" goes is much less trusted than the cloned repositories
you keep (presumably after inspecting and interacting with its
contents enough).

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Patrick Steinhardt]

On Tue, Jan 20, 2026 at 09:05:27AM -0800, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > I'm not opposed to adding support for this as an opt-in feature for
> > those people that want it, though, and I think that's the right path for
> > including it.
> 
> Yup.  I am hoping that there are no folks who think that forcing
> this filtering on everybody is so important that it must not go in
> unless it is enabled by default.

If we cannot agree then I'd rather take the opt-in compared to having
nothing at all.

> I however wonder if we need two different levels defaults, depending
> on where the user is going, to make it less painful to configure
> things.  I would imagine the remotes one would interact with fall
> into two quite different categories.
> 
>  - The ones that you talk with every day, essential in your work,
>    would be something you would have to be able to trust and if
>    these trusted people want to give you a bit more colorful output
>    from their hooks, you shouldn't have to manually configure "I
>    accept colors from them", for example.
> 
>  - There are others that you will visit for the first time as you
>    try to discover new good things.  These you may want to be extra
>    cautious about than the familiar remotes in your everyday work.
> 
> Perhaps "git clone $URL" should filter the terminal output by
> default, but once inside the resulting repository, "git push" and
> "git pull" from the established remote that is used by default when
> you do not say whom to talk to, our default can be more lenient, or
> something?

I'm not sure this would help protect our users. If we had an adversarial
remote, then it could trivially work around the protection by acting
benevolent on clone, but malicious on subsequent fetches. So it doesn't
really seem to significantly reduce the attack surface, unless I miss
something.

I think that the other suggestion you made further up the thread would
make more sense in this context. If users can configure this similar to
how our "http.<url>.*" settings work then they can e.g.:

    $ git config set --global \
        sideband."https://gitlab.com".allowControlCharacters true

And from thereon they would always trust GitLab going forward. I guess
that most users would really only need to configure two or three such
domains.

NB: This ignores the fact that GitLab.com already behaves well with the
    proposed new default as we never send ANSI escape sequences other
    than color codes. So I assume most domains wouldn't need any
    configuration in the first place.

Thanks!

Patrick

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin]

Hi Junio,

I disagree with making sideband sanitization opt-in or weakening it based
on a "trusted remote" heuristic. In this context, emitting untrusted bytes
to a terminal without proper sanitization is a security-relevant bug;
safe-by-default should be the baseline.

On Tue, 20 Jan 2026, Junio C Hamano wrote:

> [...] forcing this filtering on everybody [...]  unless it is enabled by
> default. [...]

If the goal is to mitigate terminal escape injection from
remote-controlled output, then shipping it disabled by default does not
mitigate the default case. Most users will not discover or enable a
hardening knob until after an incident.

> Two levels of defaults [...]  trusted daily remotes vs new remotes.
> [...]

I don't think we can safely infer "trusted enough to write to my terminal"
from "I fetch from there often". A previously-trusted remote can be
compromised, after all. Which means that a trust-based default is a
foot-gun: it creates a path where users believe they're protected while
the program is intentionally passing through attacker-controlled escape
sequences.

Besides, allowing "colorful output from their hooks" _is already allowed
by default_ in the proposed patch series. The config variable
`sideband.allowControlCharacters` isn't an "all or nothing" setting, after
all.

> [...] you shouldn't have to manually configure "I accept colors from
> them". [...]

Color is already a narrowly-scoped exception. Cursor movement / erase
sequences are in a different category because they can rewrite prior
output and hide what actually happened. If we want to allow them, it
should remain explicit opt-in on the client, not something we enable
automatically based on repository state.

If the argument is "setting `sideband.allowControlCharacters` to `color`
by default breaks common workflows on established remotes",
can you point to a concrete repro (hook snippet + terminal + escape
sequences relied on) or a public example? Without that, I don't think we
should bias the default toward pass-through of higher-risk sequences.

Absent such evidence, the best way to proceed is to keep sanitization
enabled by default for sideband output (modulo color), with the clearly
documented escape hatch for users who knowingly want additional sequences.
If there is a strong need for per-remote behavior, there is
`sideband.<url>.allowControlCharacters`, as per v3), i.e. users _do_ have
that option _after_ stating that they trust that particular remote not to
wreak havoc with their terminal.

Also keep in mind that this patch series' scope is the sideband channel;
The fact that SSH-based transports patch through `stderr` (completely
side-stepping sideband) is out of scope.

Ciao,
Johannes

P.S.: Junio: if we continue to discuss "opt-in"/"opt-out", I think we
need to be more explicit about which behavior we mean. We now have multiple
levels in `sideband.allowControlCharacters` (default allows color;
`cursor`, `erase`, `false` and `true` allow more fine-grained levels).

If the proposal is "full pass-through of all control characters is
opt-in", or "full sanitizing of all control characters is opt-in", I
whole-heartedly agree: That is already opt-in via setting
`sideband.allowControlCharacters` to `false` or `true`, respectively.

If the proposal is "keep the historical behavior (verbatim sideband
payload, no sanitization) as the default, and make sanitization opt-in", I
am firmly opposed: This makes the sideband payload remote-controlled; A
security hardening that is off by default will not protect the default
user population.

Can you confirm which of these two meanings you intend when you say
"opt-in" here? Once that's clarified, we can discuss whether the default
should remain at "color-only" (today's default) with explicit opt-in for
riskier sequences, or whether you're arguing for no filtering at all by
default.

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I disagree with making sideband sanitization opt-in or weakening it based
> on a "trusted remote" heuristic. In this context, emitting untrusted bytes
> to a terminal without proper sanitization is a security-relevant bug;
> safe-by-default should be the baseline.
> ...
> If the goal is to mitigate terminal escape injection from
> remote-controlled output, then shipping it disabled by default does not
> mitigate the default case. Most users will not discover or enable a
> hardening knob until after an incident.

I think we already know we disagree on this point already.  I am
simply agreeing with what brian recommended, based on his findings
at GitHub hosted public projects [*], and what Ondrej says they have
been doing in Fedora, CentOS and RHEL [*].


> I don't think we can safely infer "trusted enough to write to my terminal"
> from "I fetch from there often".

It was mostly an attempt to offer an idea: "Even if we make it off
by default, we may want to protect the initial clone, and here is
one thing you could do...".  If it would not help in practice, I am
fine if we ditch it (meaning: default off everywhere, even for the
initial contact with an unknown repository).

> If the proposal is "full pass-through of all control characters is
> opt-in", or "full sanitizing of all control characters is opt-in", I
> whole-heartedly agree: That is already opt-in via setting
> `sideband.allowControlCharacters` to `false` or `true`, respectively.
>
> If the proposal is "keep the historical behavior (verbatim sideband
> payload, no sanitization) as the default, and make sanitization opt-in", I
> am firmly opposed: This makes the sideband payload remote-controlled; A
> security hardening that is off by default will not protect the default
> user population.
>
> Can you confirm which of these two meanings you intend when you say
> "opt-in" here? Once that's clarified, we can discuss whether the default
> should remain at "color-only" (today's default) with explicit opt-in for
> riskier sequences, or whether you're arguing for no filtering at all by
> default.

The latter.

I wouldn't be surprised if people, who usually do not participate in
the discussion around here, are highly inconvenienced when we
suddenly filter out IEC/ISO 2022:1994, for example.  Not that I
suspect that these character encodings are still popular in some
parts of the world, but that I fundamentally disagree with the
attitude "we explicitly allow colors to be passed so it is perfectly
fine if we filter everything else out".


[References]

* https://lore.kernel.org/git/aWKLrIefrcSwReu2@fruit.crustytoothpaste.net/
* https://lore.kernel.org/git/CA+B51BEs7kuJ7s+K2vbZLSoaq3krGrqVncQAaTjSSNazFLY3tw@mail.gmail.com/

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2026-01-15 at 21:14:48, Jeff King wrote:
>> Is there any reason we cannot introduce the new functionality as a
>> config option but _not_ enable it by default?
>> 
>> That gives people the tools to protect themselves if they want to bear
>> the potential cost. It just feels a shame to deny them the tool because
>> we can't agree on the default.
>
> Yes, I think that would be a fine and reasonable approach.

Absolutely.

After a few weeks, however, nobody seems to have stepped up to help
us move forward (unless I missed a patch or two, of course), so here
is my attempt.  To be applied on top of Dscho's 5-patch series (v3)
that ends at c5b95e19 (sideband: offer to configure sanitizing on a
per-URL basis, 2026-01-16).

Thanks.

--- >8 ---
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 2 Feb 2026 17:06:03 -0800
Subject: [PATCH 5/4] sideband: neuter the sideband filtering

To prevent breaking settings that are working well for existing
users, tone down the sideband filtering feature and turn it off by
default.  This hopefully matches the way how distros like Fedora and
RHEL are shipping this feature in theirs.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.txt   | 14 +++++++-------
 sideband.c                          |  6 ++----
 t/t5409-colorize-remote-messages.sh | 12 ++++++++----
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/Documentation/config/sideband.txt b/Documentation/config/sideband.txt
index 32088bbf2f..d2cd86fa60 100644
--- a/Documentation/config/sideband.txt
+++ b/Documentation/config/sideband.txt
@@ -1,15 +1,15 @@
 sideband.allowControlCharacters::
-	By default, control characters that are delivered via the sideband
-	are masked, except ANSI color sequences. This prevents potentially
-	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior (the value can be
-	a comma-separated list of the following keywords):
+	By default, control characters that are delivered via the
+	sideband are all passed through.  To prevent potentially
+	unwanted ANSI escape sequences from being sent to the
+	terminal, use this config setting to override this behavior
+	(the value can be a comma-separated list of the following
+	keywords):
 +
 --
-	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
-		but mask all other control characters. This is the default.
+		but mask all other control characters.
 	`cursor:`:
 		Allow control sequences that move the cursor. This is
 		disabled by default.
diff --git a/sideband.c b/sideband.c
index a8cd142cd7..3d8534671e 100644
--- a/sideband.c
+++ b/sideband.c
@@ -61,9 +61,7 @@ int sideband_allow_control_characters_config(const char *var, const char *value)
 
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
-		if (skip_prefix_in_csv(value, "default", &value))
-			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (skip_prefix_in_csv(value, "color", &value))
+		if (skip_prefix_in_csv(value, "color", &value))
 			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
 		else if (skip_prefix_in_csv(value, "cursor", &value))
 			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
@@ -125,7 +123,7 @@ static int use_sideband_colors(void)
 			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
 
 		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
 	}
 
 	if (!git_config_get_string_tmp(key, &value))
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 1d039cbdaf..47bc8bbef2 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -107,7 +107,8 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
 
-	git clone --no-local . throw-away 2>stderr &&
+	git -c sideband.allowControlCharacters=color \
+		clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
 	test_grep RED decoded &&
 	test_grep "\\^G" stderr &&
@@ -122,7 +123,8 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
-	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	git -c sideband.allowControlCharacters \
+		clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
 	test_grep RED decoded &&
 	tr -dc "\\007" <stderr >actual &&
@@ -148,7 +150,8 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_commit need-at-least-one-commit-at-least &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c sideband.allowControlCharacters=color \
+		clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
@@ -176,7 +179,8 @@ test_expect_success 'allow all control sequences for a specific URL' '
 	test_commit one-more-please &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c sideband.allowControlCharacters=color \
+		clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
-- 
2.53.0-162-gcda875bd0b

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin]

Hi Junio,

On Tue, 3 Feb 2026, Junio C Hamano wrote:

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > On 2026-01-15 at 21:14:48, Jeff King wrote:
> >> Is there any reason we cannot introduce the new functionality as a
> >> config option but _not_ enable it by default?
> >> 
> >> That gives people the tools to protect themselves if they want to bear
> >> the potential cost. It just feels a shame to deny them the tool because
> >> we can't agree on the default.
> >
> > Yes, I think that would be a fine and reasonable approach.
> 
> Absolutely.

I disagree with neutering this security fix. Let me explain why, and then
propose a compromise.

CVE-2024-52005 exists because Git passes untrusted payload to the terminal
without sanitization. The terminal interprets control sequences sent to it
(it has no way to distinguish between sequences Git _intended_ to send and
sequences a malicious remote slipped into the sideband). That
responsibility falls squarely on Git. Shifting it to terminal emulators is
not viable: they _cannot_ make that distinction.

This is not about one specific vulnerability (OSC 8 or otherwise). It is
about the principle that programs must sanitize untrusted input before
passing it to an interpreter. Terminal emulators are interpreters. The set
of exploitable sequences changes over time as terminals add features; the
only durable fix is sanitization at the source.

Now, about breaking existing users.

The patches I submitted _do not_ break pre-receive hooks that emit color
sequences. Color sequences are allowed by default. What is disabled by
default are sequences that set the window title, query terminal state,
move the cursor, etc. (functionality that legitimate hooks have no
business using, and functionality that is ripe for exploitation).

The concern about Japanese ISO encodings colliding with control bytes is
theoretical at best: sideband messages are prefixed with the ASCII string
"remote: ", so any such encoding would already be broken today.

Here is the problem with "off by default".

Turning the sanitization off by default means CVE-2024-52005 remains
unaddressed for the vast majority of users. Providing an opt-in config is
security theater: users who do not know about the vulnerability will not
enable the protection. That is the opposite of defense in depth.

Fedora's decision to ship with sanitization disabled does not validate the
approach; it reflects their reluctance to diverge from upstream defaults,
not a security analysis concluding that the default is safe.

That said, I can see a path forward.

1. Turn sanitization _off_ by default in 2.x.
2. Document clearly that this default will change.
3. In Git 3.0 (the next breaking-changes release), flip the default so
   that `sideband.allowControlCharacters=color` is the baseline, i.e.
   color sequences pass through, but nothing else does.

This gives users and tooling (and support engineers) time to adapt while
committing to secure-by-default behavior in the near future.

I would appreciate hearing from anyone on the list with security
expertise. The principle that untrusted input must be sanitized before
reaching an interpreter is foundational; I am not aware of any credible
security guidance that says otherwise.

Ciao,
Dscho

[PATCH v4 0/6] Sanitize sideband channel messages

[Johannes Schindelin via GitGitGadget]

Git's sideband channel passes server output directly to the client terminal
without sanitizing it, creating an ANSI escape sequence injection
vulnerability (CWE-150 [https://cwe.mitre.org/data/definitions/150.html]). A
malicious or compromised server can corrupt terminal state, obscure
information, or inject characters into the terminal's input buffer (which
the terminal will interpret as if the user had typed them).

Git users have no mechanism to distinguish between Git's legitimate output
and content displayed (or hidden) via attack sequences.

This series aims to fix the vulnerability by sanitizing control characters
in the sideband output. To address concerns about existing hacks that
exploit Git's lack of sanitizing, this security fix will only kick in with
Git v3.0, where the default will change to pass ANSI color sequences (SGR
codes) through by default, since server-side hooks exist that use these for
visibility (e.g. https://github.com/kikeonline/githook-explode). By default,
all other control characters will be rendered in caret notation (e.g., ESC
becomes ^[).

Users who need different behavior get configuration options:
sideband.allowControlCharacters provides an escape hatch for environments
that require raw passthrough. The defaults in Git v3.0 will be secure.

This series applies cleanly on v2.53.0.

Changes since v3:

 * Targeting maint-2.53 now instead of maint-2.47.
 * Turned the "safe by default" behavior into a breaking change that will be
   in effect in Git v3.0.

Changes since v2:

 * Added curly brackets around a single-line if clause.
 * Enclosed the values in the documentation within backticks.
 * Aligned the enum values for better readability.
 * Added support for sideband.<url>.allowControlCharacters (à la
   http.<url>.*) on top of sideband.allowControlCharacters.

Changes since v1:

 * Applied the suggestions by Phillip and brian.
 * Rebased onto v2.47.3.
 * Added more categories of ANSI Escape sequences that can be enabled (but
   that are off by default because they could be used to hide information).

Johannes Schindelin (6):
  sideband: mask control characters
  sideband: introduce an "escape hatch" to allow control characters
  sideband: do allow ANSI color sequences by default
  sideband: add options to allow more control sequences to be passed
    through
  sideband: offer to configure sanitizing on a per-URL basis
  sideband: delay sanitizing by default to Git v3.0

 Documentation/config.adoc           |   2 +
 Documentation/config/sideband.adoc  |  39 ++++++
 sideband.c                          | 185 +++++++++++++++++++++++++++-
 sideband.h                          |  14 +++
 t/t5409-colorize-remote-messages.sh | 100 +++++++++++++++
 transport.c                         |   3 +
 6 files changed, 341 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/config/sideband.adoc


base-commit: 67ad42147a7acc2af6074753ebd03d904476118f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1853%2Fdscho%2Fsanitize-sideband-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1853/dscho/sanitize-sideband-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/1853

Range-diff vs v3:

 1:  e6b71af0ca = 1:  7addb9ca52 sideband: mask control characters
 2:  8f64d65844 ! 2:  20058534e8 sideband: introduce an "escape hatch" to allow control characters
     @@ Commit message
          Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     - ## Documentation/config.txt ##
     -@@ Documentation/config.txt: include::config/sequencer.txt[]
     + ## Documentation/config.adoc ##
     +@@ Documentation/config.adoc: include::config/sequencer.adoc[]
       
     - include::config/showbranch.txt[]
     + include::config/showbranch.adoc[]
       
     -+include::config/sideband.txt[]
     ++include::config/sideband.adoc[]
      +
     - include::config/sparse.txt[]
     + include::config/sparse.adoc[]
       
     - include::config/splitindex.txt[]
     + include::config/splitindex.adoc[]
      
     - ## Documentation/config/sideband.txt (new) ##
     + ## Documentation/config/sideband.adoc (new) ##
      @@
      +sideband.allowControlCharacters::
      +	By default, control characters that are delivered via the sideband
     @@ sideband.c: static struct keyword_entry keywords[] = {
      +static int allow_control_characters;
      +
       /* Returns a color setting (GIT_COLOR_NEVER, etc). */
     - static int use_sideband_colors(void)
     + static enum git_colorbool use_sideband_colors(void)
       {
     -@@ sideband.c: static int use_sideband_colors(void)
     - 	if (use_sideband_colors_cached >= 0)
     +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
     + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
       		return use_sideband_colors_cached;
       
     -+	git_config_get_bool("sideband.allowcontrolcharacters",
     ++	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
      +			    &allow_control_characters);
      +
     - 	if (!git_config_get_string_tmp(key, &value))
     + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
       		use_sideband_colors_cached = git_config_colorbool(key, value);
     - 	else if (!git_config_get_string_tmp("color.ui", &value))
     + 	else if (!repo_config_get_string_tmp(the_repository, "color.ui", &value))
      @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref
       
       static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 3:  44838acacc ! 3:  919111f590 sideband: do allow ANSI color sequences by default
     @@ Commit message
      
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     - ## Documentation/config/sideband.txt ##
     + ## Documentation/config/sideband.adoc ##
      @@
       sideband.allowControlCharacters::
       	By default, control characters that are delivered via the sideband
     @@ sideband.c: static struct keyword_entry keywords[] = {
      +} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
       
       /* Returns a color setting (GIT_COLOR_NEVER, etc). */
     - static int use_sideband_colors(void)
     -@@ sideband.c: static int use_sideband_colors(void)
     - 	if (use_sideband_colors_cached >= 0)
     + static enum git_colorbool use_sideband_colors(void)
     +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
     + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
       		return use_sideband_colors_cached;
       
     --	git_config_get_bool("sideband.allowcontrolcharacters",
     +-	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
      -			    &allow_control_characters);
     -+	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
     ++	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
      +	case 0: /* Boolean value */
      +		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
      +			ALLOW_NO_CONTROL_CHARACTERS;
      +		break;
      +	case -1: /* non-Boolean value */
     -+		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
     ++		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
      +					      &value))
      +			; /* huh? `get_maybe_bool()` returned -1 */
      +		else if (!strcmp(value, "default"))
     @@ sideband.c: static int use_sideband_colors(void)
      +		break; /* not configured */
      +	}
       
     - 	if (!git_config_get_string_tmp(key, &value))
     + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
       		use_sideband_colors_cached = git_config_colorbool(key, value);
      @@ sideband.c: void list_config_color_sideband_slots(struct string_list *list, const char *pref
       		list_config_item(list, prefix, keywords[i].keyword);
 4:  cc578465b9 ! 4:  ec48f1cba1 sideband: add options to allow more control sequences to be passed through
     @@ Commit message
      
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     - ## Documentation/config/sideband.txt ##
     -@@ Documentation/config/sideband.txt: sideband.allowControlCharacters::
     + ## Documentation/config/sideband.adoc ##
     +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
       	By default, control characters that are delivered via the sideband
       	are masked, except ANSI color sequences. This prevents potentially
       	unwanted ANSI escape sequences from being sent to the terminal. Use
     @@ sideband.c: static struct keyword_entry keywords[] = {
      +}
       
       /* Returns a color setting (GIT_COLOR_NEVER, etc). */
     - static int use_sideband_colors(void)
     -@@ sideband.c: static int use_sideband_colors(void)
     - 		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
     + static enum git_colorbool use_sideband_colors(void)
     +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
     + 		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
       					      &value))
       			; /* huh? `get_maybe_bool()` returned -1 */
      -		else if (!strcmp(value, "default"))
 5:  f2eb0a758c ! 5:  692d1a63ed sideband: offer to configure sanitizing on a per-URL basis
     @@ Commit message
          Suggested-by: Junio Hamano <gitster@pobox.com>
          Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
      
     - ## Documentation/config/sideband.txt ##
     -@@ Documentation/config/sideband.txt: sideband.allowControlCharacters::
     + ## Documentation/config/sideband.adoc ##
     +@@ Documentation/config/sideband.adoc: sideband.allowControlCharacters::
       	`true`::
       		Allow all control characters to be sent to the terminal.
       --
     @@ sideband.c: static void parse_allow_control_characters(const char *value)
      +	config.collect_fn = sideband_config_callback;
      +
      +	normalized_url = url_normalize(url, &config.url);
     -+	git_config(urlmatch_config_entry, &config);
     ++	repo_config(the_repository, urlmatch_config_entry, &config);
      +	free(normalized_url);
      +	string_list_clear(&config.vars, 1);
      +	urlmatch_config_release(&config);
       }
       
       /* Returns a color setting (GIT_COLOR_NEVER, etc). */
     -@@ sideband.c: static int use_sideband_colors(void)
     - 	if (use_sideband_colors_cached >= 0)
     +@@ sideband.c: static enum git_colorbool use_sideband_colors(void)
     + 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
       		return use_sideband_colors_cached;
       
     --	switch (git_config_get_maybe_bool("sideband.allowcontrolcharacters", &i)) {
     +-	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
      -	case 0: /* Boolean value */
      -		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
      -			ALLOW_NO_CONTROL_CHARACTERS;
      -		break;
      -	case -1: /* non-Boolean value */
     --		if (git_config_get_string_tmp("sideband.allowcontrolcharacters",
     +-		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
      -					      &value))
      -			; /* huh? `get_maybe_bool()` returned -1 */
      -		else
     @@ sideband.c: static int use_sideband_colors(void)
      -	default:
      -		break; /* not configured */
      +	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
     -+		if (!git_config_get_value("sideband.allowcontrolcharacters", &value))
     ++		if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value))
      +			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
      +
      +		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
      +			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
       	}
       
     - 	if (!git_config_get_string_tmp(key, &value))
     + 	if (!repo_config_get_string_tmp(the_repository, key, &value))
      
       ## sideband.h ##
      @@ sideband.h: int demultiplex_sideband(const char *me, int status,
     @@ transport.c
       #include "bundle-uri.h"
      +#include "sideband.h"
       
     - static int transport_use_color = -1;
     + static enum git_colorbool transport_use_color = GIT_COLOR_UNKNOWN;
       static char transport_colors[][COLOR_MAXLEN] = {
      @@ transport.c: struct transport *transport_get(struct remote *remote, const char *url)
       
     - 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1];
     + 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1_LEGACY];
       
      +	sideband_apply_url_config(ret->url);
      +
 -:  ---------- > 6:  8b8244eca9 sideband: delay sanitizing by default to Git v3.0

-- 
gitgitgadget

[PATCH v4 1/6] sideband: mask control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The output of `git clone` is a vital component for understanding what
has happened when things go wrong. However, these logs are partially
under the control of the remote server (via the "sideband", which
typically contains what the remote `git pack-objects` process sends to
`stderr`), and is currently not sanitized by Git.

This makes Git susceptible to ANSI escape sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
attackers to corrupt terminal state, to hide information, and even to
insert characters into the input buffer (i.e. as if the user had typed
those characters).

To plug this vulnerability, disallow any control character in the
sideband, replacing them instead with the common `^<letter/symbol>`
(e.g. `^[` for `\x1b`, `^A` for `\x01`).

There is likely a need for more fine-grained controls instead of using a
"heavy hammer" like this, which will be introduced subsequently.

Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 sideband.c                          | 17 +++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 12 ++++++++++++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/sideband.c b/sideband.c
index ea7c25211e..c1bbadccac 100644
--- a/sideband.c
+++ b/sideband.c
@@ -66,6 +66,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
+{
+	strbuf_grow(dest, n);
+	for (; n && *src; src++, n--) {
+		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
+			strbuf_addch(dest, *src);
+		} else {
+			strbuf_addch(dest, '^');
+			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
+		}
+	}
+}
+
 /*
  * Optionally highlight one keyword in remote output if it appears at the start
  * of the line. This should be called for a single line only, which is
@@ -81,7 +94,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 	int i;
 
 	if (!want_color_stderr(use_sideband_colors())) {
-		strbuf_add(dest, src, n);
+		strbuf_add_sanitized(dest, src, n);
 		return;
 	}
 
@@ -114,7 +127,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 		}
 	}
 
-	strbuf_add(dest, src, n);
+	strbuf_add_sanitized(dest, src, n);
 }
 
 
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index fa5de4500a..aa5b570571 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -98,4 +98,16 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+test_expect_success 'disallow (color) control sequences in sideband' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep ! RED decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH v4 2/6] sideband: introduce an "escape hatch" to allow control characters

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding commit fixed the vulnerability whereas sideband messages
(that are under the control of the remote server) could contain ANSI
escape sequences that would be sent to the terminal verbatim.

However, this fix may not be desirable under all circumstances, e.g.
when remote servers deliberately add coloring to their messages to
increase their urgency.

To help with those use cases, give users a way to opt-out of the
protections: `sideband.allowControlCharacters`.

Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config.adoc           |  2 ++
 Documentation/config/sideband.adoc  |  5 +++++
 sideband.c                          | 10 ++++++++++
 t/t5409-colorize-remote-messages.sh |  8 +++++++-
 4 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/config/sideband.adoc

diff --git a/Documentation/config.adoc b/Documentation/config.adoc
index 62eebe7c54..dcea3c0c15 100644
--- a/Documentation/config.adoc
+++ b/Documentation/config.adoc
@@ -523,6 +523,8 @@ include::config/sequencer.adoc[]
 
 include::config/showbranch.adoc[]
 
+include::config/sideband.adoc[]
+
 include::config/sparse.adoc[]
 
 include::config/splitindex.adoc[]
diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
new file mode 100644
index 0000000000..3fb5045cd7
--- /dev/null
+++ b/Documentation/config/sideband.adoc
@@ -0,0 +1,5 @@
+sideband.allowControlCharacters::
+	By default, control characters that are delivered via the sideband
+	are masked, to prevent potentially unwanted ANSI escape sequences
+	from being sent to the terminal. Use this config setting to override
+	this behavior.
diff --git a/sideband.c b/sideband.c
index c1bbadccac..682f1cbbed 100644
--- a/sideband.c
+++ b/sideband.c
@@ -26,6 +26,8 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
+static int allow_control_characters;
+
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
 {
@@ -39,6 +41,9 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
+	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
+			    &allow_control_characters);
+
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
 	else if (!repo_config_get_string_tmp(the_repository, "color.ui", &value))
@@ -68,6 +73,11 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
+	if (allow_control_characters) {
+		strbuf_add(dest, src, n);
+		return;
+	}
+
 	strbuf_grow(dest, n);
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index aa5b570571..9caee9a07f 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -105,9 +105,15 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
+
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep ! RED decoded
+	test_grep ! RED decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep RED decoded
 '
 
 test_done
-- 
gitgitgadget

[PATCH v4 3/6] sideband: do allow ANSI color sequences by default

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding two commits introduced special handling of the sideband
channel to neutralize ANSI escape sequences before sending the payload
to the terminal, and `sideband.allowControlCharacters` to override that
behavior.

However, as reported by brian m. carlson, some `pre-receive` hooks that
are actively used in practice want to color their messages and therefore
rely on the fact that Git passes them through to the terminal, even
though they have no way to determine whether the receiving side can
actually handle Escape sequences (think e.g. about the practice
recommended by Git that third-party applications wishing to use Git
functionality parse the output of Git commands).

In contrast to other ANSI escape sequences, it is highly unlikely that
coloring sequences can be essential tools in attack vectors that mislead
Git users e.g. by hiding crucial information.

Therefore we can have both: Continue to allow ANSI coloring sequences to
be passed to the terminal by default, and neutralize all other ANSI
Escape sequences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.adoc  | 18 ++++++--
 sideband.c                          | 66 +++++++++++++++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 16 ++++++-
 3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 3fb5045cd7..b55c73726f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -1,5 +1,17 @@
 sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
-	are masked, to prevent potentially unwanted ANSI escape sequences
-	from being sent to the terminal. Use this config setting to override
-	this behavior.
+	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal. Use
+	this config setting to override this behavior:
++
+--
+	`default`::
+	`color`::
+		Allow ANSI color sequences, line feeds and horizontal tabs,
+		but mask all other control characters. This is the default.
+	`false`::
+		Mask all control characters other than line feeds and
+		horizontal tabs.
+	`true`::
+		Allow all control characters to be sent to the terminal.
+--
diff --git a/sideband.c b/sideband.c
index 682f1cbbed..eeba6fa2ca 100644
--- a/sideband.c
+++ b/sideband.c
@@ -26,7 +26,12 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
-static int allow_control_characters;
+static enum {
+	ALLOW_NO_CONTROL_CHARACTERS  = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
+} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
@@ -41,8 +46,26 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
-	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
-			    &allow_control_characters);
+	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
+	case 0: /* Boolean value */
+		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
+			ALLOW_NO_CONTROL_CHARACTERS;
+		break;
+	case -1: /* non-Boolean value */
+		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
+					      &value))
+			; /* huh? `get_maybe_bool()` returned -1 */
+		else if (!strcmp(value, "default"))
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (!strcmp(value, "color"))
+			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+		break;
+	default:
+		break; /* not configured */
+	}
 
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
@@ -71,9 +94,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+{
+	int i;
+
+	/*
+	 * Valid ANSI color sequences are of the form
+	 *
+	 * ESC [ [<n> [; <n>]*] m
+	 *
+	 * These are part of the Select Graphic Rendition sequences which
+	 * contain more than just color sequences, for more details see
+	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 */
+
+	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
+	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+		return 0;
+
+	for (i = 2; i < n; i++) {
+		if (src[i] == 'm') {
+			strbuf_add(dest, src, i + 1);
+			return i;
+		}
+		if (!isdigit(src[i]) && src[i] != ';')
+			break;
+	}
+
+	return 0;
+}
+
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
-	if (allow_control_characters) {
+	int i;
+
+	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -82,6 +137,9 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
+		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+			src += i;
+			n -= i;
 		} else {
 			strbuf_addch(dest, '^');
 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 9caee9a07f..e5092d3b42 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -100,7 +100,7 @@ test_expect_success 'fallback to color.ui' '
 
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
-	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
@@ -108,12 +108,24 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
+	test_grep RED decoded &&
+	test_grep "\\^G" stderr &&
+	tr -dc "\\007" <stderr >actual &&
+	test_must_be_empty actual &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=false \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
 	test_grep ! RED decoded &&
+	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
 	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep RED decoded
+	test_grep RED decoded &&
+	tr -dc "\\007" <stderr >actual &&
+	test_file_not_empty actual
 '
 
 test_done
-- 
gitgitgadget

[PATCH v4 4/6] sideband: add options to allow more control sequences to be passed through

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Even though control sequences that erase characters are quite juicy for
attack scenarios, where attackers are eager to hide traces of suspicious
activities, during the review of the side band sanitizing patch series
concerns were raised that there might be some legimitate scenarios where
Git server's `pre-receive` hooks use those sequences in a benign way.

Control sequences to move the cursor can likewise be used to hide tracks
by overwriting characters, and have been equally pointed out as having
legitimate users.

Let's add options to let users opt into passing through those ANSI
Escape sequences: `sideband.allowControlCharacters` now supports also
`cursor` and `erase`, and it parses the value as a comma-separated list.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.adoc  |  9 ++-
 sideband.c                          | 91 ++++++++++++++++++++++++-----
 t/t5409-colorize-remote-messages.sh | 38 ++++++++++++
 3 files changed, 123 insertions(+), 15 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index b55c73726f..2bf0426284 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -2,13 +2,20 @@ sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
 	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior:
+	this config setting to override this behavior (the value can be
+	a comma-separated list of the following keywords):
 +
 --
 	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
+	`cursor:`:
+		Allow control sequences that move the cursor. This is
+		disabled by default.
+	`erase`::
+		Allow control sequences that erase charactrs. This is
+		disabled by default.
 	`false`::
 		Mask all control characters other than line feeds and
 		horizontal tabs.
diff --git a/sideband.c b/sideband.c
index eeba6fa2ca..0b420ca319 100644
--- a/sideband.c
+++ b/sideband.c
@@ -29,9 +29,43 @@ static struct keyword_entry keywords[] = {
 static enum {
 	ALLOW_NO_CONTROL_CHARACTERS  = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
+	ALLOW_ANSI_ERASE             = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
+} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+
+static inline int skip_prefix_in_csv(const char *value, const char *prefix,
+				     const char **out)
+{
+	if (!skip_prefix(value, prefix, &value) ||
+	    (*value && *value != ','))
+		return 0;
+	*out = value + !!*value;
+	return 1;
+}
+
+static void parse_allow_control_characters(const char *value)
+{
+	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+	while (*value) {
+		if (skip_prefix_in_csv(value, "default", &value))
+			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "color", &value))
+			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "cursor", &value))
+			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
+		else if (skip_prefix_in_csv(value, "erase", &value))
+			allow_control_characters |= ALLOW_ANSI_ERASE;
+		else if (skip_prefix_in_csv(value, "true", &value))
+			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		else if (skip_prefix_in_csv(value, "false", &value))
+			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+	}
+}
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
@@ -55,13 +89,8 @@ static enum git_colorbool use_sideband_colors(void)
 		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
 					      &value))
 			; /* huh? `get_maybe_bool()` returned -1 */
-		else if (!strcmp(value, "default"))
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (!strcmp(value, "color"))
-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			parse_allow_control_characters(value);
 		break;
 	default:
 		break; /* not configured */
@@ -94,7 +123,7 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
@@ -106,14 +135,47 @@ static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
 	 * These are part of the Select Graphic Rendition sequences which
 	 * contain more than just color sequences, for more details see
 	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 *
+	 * The cursor movement sequences are:
+	 *
+	 * ESC [ n A - Cursor up n lines (CUU)
+	 * ESC [ n B - Cursor down n lines (CUD)
+	 * ESC [ n C - Cursor forward n columns (CUF)
+	 * ESC [ n D - Cursor back n columns (CUB)
+	 * ESC [ n E - Cursor next line, beginning (CNL)
+	 * ESC [ n F - Cursor previous line, beginning (CPL)
+	 * ESC [ n G - Cursor to column n (CHA)
+	 * ESC [ n ; m H - Cursor position (row n, col m) (CUP)
+	 * ESC [ n ; m f - Same as H (HVP)
+	 *
+	 * The sequences to erase characters are:
+	 *
+	 *
+	 * ESC [ 0 J - Clear from cursor to end of screen (ED)
+	 * ESC [ 1 J - Clear from cursor to beginning of screen (ED)
+	 * ESC [ 2 J - Clear entire screen (ED)
+	 * ESC [ 3 J - Clear entire screen + scrollback (ED) - xterm extension
+	 * ESC [ 0 K - Clear from cursor to end of line (EL)
+	 * ESC [ 1 K - Clear from cursor to beginning of line (EL)
+	 * ESC [ 2 K - Clear entire line (EL)
+	 * ESC [ n M - Delete n lines (DL)
+	 * ESC [ n P - Delete n characters (DCH)
+	 * ESC [ n X - Erase n characters (ECH)
+	 *
+	 * For a comprehensive list of common ANSI Escape sequences, see
+	 * https://www.xfree86.org/current/ctlseqs.html
 	 */
 
-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+	if (n < 3 || src[0] != '\x1b' || src[1] != '[')
 		return 0;
 
 	for (i = 2; i < n; i++) {
-		if (src[i] == 'm') {
+		if (((allow_control_characters & ALLOW_ANSI_COLOR_SEQUENCES) &&
+		     src[i] == 'm') ||
+		    ((allow_control_characters & ALLOW_ANSI_CURSOR_MOVEMENTS) &&
+		     strchr("ABCDEFGHf", src[i])) ||
+		    ((allow_control_characters & ALLOW_ANSI_ERASE) &&
+		     strchr("JKMPX", src[i]))) {
 			strbuf_add(dest, src, i + 1);
 			return i;
 		}
@@ -128,7 +190,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
+	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -137,7 +199,8 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
-		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+		} else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
+			   (i = handle_ansi_sequence(dest, src, n))) {
 			src += i;
 			n -= i;
 		} else {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index e5092d3b42..896e790bf9 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -128,4 +128,42 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_file_not_empty actual
 '
 
+test_decode_csi() {
+	awk '{
+		while (match($0, /\033/) != 0) {
+			printf "%sCSI ", substr($0, 1, RSTART-1);
+			$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
+		}
+		print
+	}'
+}
+
+test_expect_success 'control sequences in sideband allowed by default' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit-at-least &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep ! "CSI \\[G" decoded &&
+	test_grep "\\^\\[?25l" decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=erase,cursor,color \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "RED" decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep "CSI \\[G" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded &&
+	test_grep ! "\\^\\[\\[G" decoded
+'
+
 test_done
-- 
gitgitgadget

[PATCH v4 5/6] sideband: offer to configure sanitizing on a per-URL basis

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The main objection against sanitizing the sideband that was raised
during the review of the sideband sanitizing patches, first on the
git-security mailing list, then on the public mailing list, was that
there are some setups where server-side `pre-receive` hooks want to
error out, giving colorful messages to the users on the client side (if
they are not redirecting the output into a file, that is).

To avoid breaking such setups, the default chosen by the sideband
sanitizing patches is to pass through ANSI color sequences.

Still, there might be some use case out there where that is not enough.
Therefore the `sideband.allowControlCharacters` config setting allows
for configuring  levels of sanitizing.

As Junio Hamano pointed out, to keep users safe by default, we need to
be able to scope this to some servers because while a user may trust
their company's Git server, the same might not apply to other Git
servers.

To allow for this, let's imitate the way `http.<url>.*` offers
to scope config settings to certain URLs, by letting users
override the `sideband.allowControlCharacters` setting via
`sideband.<url>.allowControlCharacters`.

Suggested-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.adoc  |  4 ++
 sideband.c                          | 81 ++++++++++++++++++++---------
 sideband.h                          | 14 +++++
 t/t5409-colorize-remote-messages.sh | 24 +++++++++
 transport.c                         |  3 ++
 5 files changed, 102 insertions(+), 24 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 2bf0426284..32088bbf2f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -22,3 +22,7 @@ sideband.allowControlCharacters::
 	`true`::
 		Allow all control characters to be sent to the terminal.
 --
+
+sideband.<url>.*::
+	Apply the `sideband.*` option selectively to specific URLs. The
+	same URL matching logic applies as for `http.<url>.*` settings.
diff --git a/sideband.c b/sideband.c
index 0b420ca319..a90db9e288 100644
--- a/sideband.c
+++ b/sideband.c
@@ -10,6 +10,7 @@
 #include "help.h"
 #include "pkt-line.h"
 #include "write-or-die.h"
+#include "urlmatch.h"
 
 struct keyword_entry {
 	/*
@@ -27,13 +28,14 @@ static struct keyword_entry keywords[] = {
 };
 
 static enum {
-	ALLOW_NO_CONTROL_CHARACTERS  = 0,
-	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
-	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
-	ALLOW_ANSI_ERASE             = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
-} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
+	ALLOW_NO_CONTROL_CHARACTERS   = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
+	ALLOW_ANSI_ERASE              = 1<<2,
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+} allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 				     const char **out)
@@ -45,8 +47,19 @@ static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 	return 1;
 }
 
-static void parse_allow_control_characters(const char *value)
+int sideband_allow_control_characters_config(const char *var, const char *value)
 {
+	switch (git_parse_maybe_bool(value)) {
+	case 0:
+		allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		return 0;
+	case 1:
+		allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		return 0;
+	default:
+		break;
+	}
+
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
 		if (skip_prefix_in_csv(value, "default", &value))
@@ -62,9 +75,37 @@ static void parse_allow_control_characters(const char *value)
 		else if (skip_prefix_in_csv(value, "false", &value))
 			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			warning(_("unrecognized value for '%s': '%s'"), var, value);
 	}
+	return 0;
+}
+
+static int sideband_config_callback(const char *var, const char *value,
+				    const struct config_context *ctx UNUSED,
+				    void *data UNUSED)
+{
+	if (!strcmp(var, "sideband.allowcontrolcharacters"))
+		return sideband_allow_control_characters_config(var, value);
+
+	return 0;
+}
+
+void sideband_apply_url_config(const char *url)
+{
+	struct urlmatch_config config = URLMATCH_CONFIG_INIT;
+	char *normalized_url;
+
+	if (!url)
+		BUG("must not call sideband_apply_url_config(NULL)");
+
+	config.section = "sideband";
+	config.collect_fn = sideband_config_callback;
+
+	normalized_url = url_normalize(url, &config.url);
+	repo_config(the_repository, urlmatch_config_entry, &config);
+	free(normalized_url);
+	string_list_clear(&config.vars, 1);
+	urlmatch_config_release(&config);
 }
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
@@ -80,20 +121,12 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
-	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
-	case 0: /* Boolean value */
-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
-			ALLOW_NO_CONTROL_CHARACTERS;
-		break;
-	case -1: /* non-Boolean value */
-		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
-					      &value))
-			; /* huh? `get_maybe_bool()` returned -1 */
-		else
-			parse_allow_control_characters(value);
-		break;
-	default:
-		break; /* not configured */
+	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
+		if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value))
+			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
+
+		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
 	}
 
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
diff --git a/sideband.h b/sideband.h
index 5a25331be5..d15fa4015f 100644
--- a/sideband.h
+++ b/sideband.h
@@ -30,4 +30,18 @@ int demultiplex_sideband(const char *me, int status,
 
 void send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
 
+/*
+ * Apply sideband configuration for the given URL. This should be called
+ * when a transport is created to allow URL-specific configuration of
+ * sideband behavior (e.g., sideband.<url>.allowControlCharacters).
+ */
+void sideband_apply_url_config(const char *url);
+
+/*
+ * Parse and set the sideband allow control characters configuration.
+ * The var parameter should be the key name (without section prefix).
+ * Returns 0 if the variable was recognized and handled, non-zero otherwise.
+ */
+int sideband_allow_control_characters_config(const char *var, const char *value);
+
 #endif
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 896e790bf9..3010913bb1 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -166,4 +166,28 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_grep ! "\\^\\[\\[G" decoded
 '
 
+test_expect_success 'allow all control sequences for a specific URL' '
+	write_script .git/eraser <<-\EOF &&
+	printf "error: Ohai!\\r\\033[K" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./eraser &&
+	test_commit one-more-please &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep "\\^\\[\\[K" decoded &&
+
+	rm -rf throw-away &&
+	git -c "sideband.file://.allowControlCharacters=true" \
+		clone --no-local "file://$PWD" throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded
+'
+
 test_done
diff --git a/transport.c b/transport.c
index c7f06a7382..1602065953 100644
--- a/transport.c
+++ b/transport.c
@@ -29,6 +29,7 @@
 #include "object-name.h"
 #include "color.h"
 #include "bundle-uri.h"
+#include "sideband.h"
 
 static enum git_colorbool transport_use_color = GIT_COLOR_UNKNOWN;
 static char transport_colors[][COLOR_MAXLEN] = {
@@ -1245,6 +1246,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1_LEGACY];
 
+	sideband_apply_url_config(ret->url);
+
 	return ret;
 }
 
-- 
gitgitgadget

[PATCH v4 6/6] sideband: delay sanitizing by default to Git v3.0

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The sideband sanitization patches allow ANSI color sequences through
by default, preserving compatibility with pre-receive hooks that
provide colored output during `git push`.

Even so, there is concern that changing any default behavior in a
minor release may have unforeseen consequences. To accommodate this,
defer the secure-by-default behavior to Git v3.0, where breaking
changes are expected.

This gives users and tooling time to prepare, while committing to
address CVE-2024-52005 in Git v3.0.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/config/sideband.adoc  | 11 +++++++++++
 sideband.c                          |  6 +++++-
 t/t5409-colorize-remote-messages.sh | 18 +++++++++++++-----
 3 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 32088bbf2f..800a10a1ef 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -1,12 +1,23 @@
 sideband.allowControlCharacters::
+ifdef::with-breaking-changes[]
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
+endif::with-breaking-changes[]
+ifndef::with-breaking-changes[]
+	By default, no control characters delivered via the sideband
+	are masked. This is unsafe and will change in Git v3.* to only
+	allow ANSI color sequences by default, preventing potentially
+endif::with-breaking-changes[]
 	unwanted ANSI escape sequences from being sent to the terminal. Use
 	this config setting to override this behavior (the value can be
 	a comma-separated list of the following keywords):
 +
 --
 	`default`::
+ifndef::with-breaking-changes[]
+		Allow any control sequence. This default is unsafe and will
+		change to `color` in Git v3.*.
+endif::with-breaking-changes[]
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
diff --git a/sideband.c b/sideband.c
index a90db9e288..650d00b36e 100644
--- a/sideband.c
+++ b/sideband.c
@@ -33,8 +33,12 @@ static enum {
 	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
 	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
 	ALLOW_ANSI_ERASE              = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
 	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+#ifdef WITH_BREAKING_CHANGES
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+#else
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ALL_CONTROL_CHARACTERS,
+#endif
 } allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 3010913bb1..07cbc62736 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -98,6 +98,13 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+if test_have_prereq WITH_BREAKING_CHANGES
+then
+	TURN_ON_SANITIZING=already.turned=on
+else
+	TURN_ON_SANITIZING=sideband.allowControlCharacters=color
+fi
+
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
@@ -106,7 +113,7 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
 
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
 	test_grep RED decoded &&
 	test_grep "\\^G" stderr &&
@@ -138,7 +145,7 @@ test_decode_csi() {
 	}'
 }
 
-test_expect_success 'control sequences in sideband allowed by default' '
+test_expect_success 'control sequences in sideband allowed by default (in Git v3.8)' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
 	exec "$@"
@@ -147,7 +154,7 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_commit need-at-least-one-commit-at-least &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
@@ -175,14 +182,15 @@ test_expect_success 'allow all control sequences for a specific URL' '
 	test_commit one-more-please &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
 	test_grep "\\^\\[\\[K" decoded &&
 
 	rm -rf throw-away &&
-	git -c "sideband.file://.allowControlCharacters=true" \
+	git -c sideband.allowControlCharacters=false \
+		-c "sideband.file://.allowControlCharacters=true" \
 		clone --no-local "file://$PWD" throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
-- 
gitgitgadget

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Just this point, as I do not have time to deal with this topic right
now.

> The concern about Japanese ISO encodings colliding with control bytes is
> theoretical at best: sideband messages are prefixed with the ASCII string
> "remote: ", so any such encoding would already be broken today.

This is false.  

ISO/IEC 2022 is designed to allow mixing different encodings
(including ASCII), and it is a common practice to mix in a Japanese
string (or any of your choice) enclosed in a pair of "ESC $ B"
(note: 'B' is for Japanese, but other character encoding can be
specified in the same string by using a different letter here) and
"ESC ( B" to go back to ASCII.  So if you throw "remote: " at the
beginning, that comes out in ASCII.  The payload may have ISO/IEC
2022 encoded "foreign" letters, but again, they are closed with "ESC
( B" to switch back to ASCII, if you add random junk (like "..."
perhaps) after them in ASCII, your random junk will come out in
ASCII just fine.

Re: [PATCH v4 0/6] Sanitize sideband channel messages

[Junio C Hamano]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> Git's sideband channel passes server output directly to the client terminal
> without sanitizing it, creating an ANSI escape sequence injection
> vulnerability (CWE-150 [https://cwe.mitre.org/data/definitions/150.html]). A
> malicious or compromised server can corrupt terminal state, obscure
> information, or inject characters into the terminal's input buffer (which
> the terminal will interpret as if the user had typed them).
>
> Git users have no mechanism to distinguish between Git's legitimate output
> and content displayed (or hidden) via attack sequences.
>
> This series aims to fix the vulnerability by sanitizing control characters
> in the sideband output. To address concerns about existing hacks that
> exploit Git's lack of sanitizing, this security fix will only kick in with
> Git v3.0, where the default will change to pass ANSI color sequences (SGR
> codes) through by default, since server-side hooks exist that use these for
> visibility (e.g. https://github.com/kikeonline/githook-explode). By default,
> all other control characters will be rendered in caret notation (e.g., ESC
> becomes ^[).
>
> Users who need different behavior get configuration options:
> sideband.allowControlCharacters provides an escape hatch for environments
> that require raw passthrough. The defaults in Git v3.0 will be secure.
>
> This series applies cleanly on v2.53.0.

Thanks for an updated series.  They applied cleanly and merged
cleanly to 'seen'.

I have three problems with this round, some minor, some fundamental.

 * There is a value "default" that the user can use to configure it,
   which changes its behaviour across Git 3.0 version boundary.  I
   think this is a horrible design.  Those who do not configure may
   be showing their acceptance "I can go with whatever the tool's
   designers choose with the option, and if that changes in the
   middle, I can adapt", but for those who do, the configuration is
   a mechanism, an escape hatch, to express their preference and
   avoid getting disrupted by future change of behaviour.

   Fixing it is easy here; just remove "default".  Those who want to
   live in the fiture earlycan set it to "color" and it will stay
   valid across Git 3.0 version boundary.  Those who want to make
   sure their control sequences won't be broken can set it to "pass
   everything" and it will stay valid across Git 3.0 version
   boundary.

 * I would have preferred to see the early parts of the series all
   being opt-in, and that subset of the series be able to graduate
   earlier.  Way earlier than the default flip to prove that they do
   not hurt when unconfigured (they are theoretically no-op while
   being opt-in, but we want to make sure), and that they do help
   when configured.  And then once we are satisfied, the default
   flip can be discussed and applied.

 * The overall approach is "we know better than our users what
   control sequences we want to pass, so we will write code to
   recognize these small number of control sequences and allow
   them", which I am worried that would put more users at risk.

   But the thing is that our code may not know better than the users
   what control sequences, which have little security implications,
   users want to use in the payload between their servers and their
   desktop clients.  What happens to these users who use the control
   sequences that the code does not recognize and still want to keep
   using them?  They have to either

     (1) write code to teach git to recognize their control
         sequences (perhaps they do want ISO/IEC 2022 passed) and
         tweak the allowlist mechanism to support it, or

     (2) use the allowlist mechanism to pass everything, even the
         sequences they are not interested in passing that have
         security implications.

   Most of them I suspect will do the latter, which is not what we
   want to see.

   Can't we do this the other way around?  The code may not be able
   to know what control sequences the users may want to use better
   than the users, but the code (and the author of the code) should
   know what control sequences have negative security implications
   much better than the users.  Instead of teaching the code to
   recognize control sequences to color strings [*} that have little
   security implications, can we teach the code to recognise control
   sequences that we do *not* want to pass and neuter them, without
   molesting control sequences with little security implications
   that users may want to use?

Thanks.


[Footnote]

 * or sequences to go multi-lingual over 7-bit by using ISO/IEC
   2022 ;-)

Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
> index 1d039cbdaf..47bc8bbef2 100755
> --- a/t/t5409-colorize-remote-messages.sh
> +++ b/t/t5409-colorize-remote-messages.sh
> @@ -107,7 +107,8 @@ test_expect_success 'disallow (color) control sequences in sideband' '
>  	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
>  	test_commit need-at-least-one-commit &&
>  
> -	git clone --no-local . throw-away 2>stderr &&
> +	git -c sideband.allowControlCharacters=color \
> +		clone --no-local . throw-away 2>stderr &&
>  	test_decode_color <stderr >decoded &&
>  	test_grep RED decoded &&
>  	test_grep "\\^G" stderr &&

While I was mucking with this part of the test, this test piece
reminded me that I myself often use a control sequence

    ESC ] 0; <my string> BEL

in a time-consuming program to say which step of the whole thing it
is currently running.

This sequence updates the terminal's title, so in one of my terminal
tab, I start such a time-consuming program, switch to another tab
that is showing another terminal, and let it run.  It will report me
its progress by changing the terminal's title every once in a while.

I would not frown at people who want to do the same over the network
between the servers they control and their desktop client.  Even
though the server is not friendly to those who do not run terminal
that support such a control sequence, that is strictly between the
server and the end-user who talks with the server.

And neutering BEL of course will break such a user, unless the user
says "ok, if I need to pass everything in order to pass BEL, then so
be it".  That is a bit sad.

Re: [PATCH v4 0/6] Sanitize sideband channel messages

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>  * I would have preferred to see the early parts of the series all
>    being opt-in, and that subset of the series be able to graduate
>    earlier.  Way earlier than the default flip to prove that they do
>    not hurt when unconfigured (they are theoretically no-op while
>    being opt-in, but we want to make sure), and that they do help
>    when configured.  And then once we are satisfied, the default
>    flip can be discussed and applied.

Thinking about this a bit more, I see a strong reason to prefer the
way the series in this iteration is constructed.  We could merge the
early parts down to 'next' well before the last piece, and hopefully
we will know how much what they are already using breaks (and we
know colors are use in the field, and we know by default we pass
colors, so this is to catch other uses of control sequences) by
filtering among those who are running 'next' for their every-day
work, before the main part of the series leaves 'master'.

If we did it the other way around, even if we mergee everything to
'next', the guinea-pig population will be limited to those who build
'next' with WITH_BREAKING_CHANGES, which would be a lot smaller
minority (I suspect that nobody uses a build with
WITH_BREAKING_CHANGES for their every-day work, actually).

So I no longer think the "no-op by default first and then tighten at
the end with WITH_BREAKING_CHANGES" is my preference.

Thanks.

Re: [PATCH v4 0/6] Sanitize sideband channel messages

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>  * I would have preferred to see the early parts of the series all
>>    being opt-in, and that subset of the series be able to graduate
>>    earlier.  Way earlier than the default flip to prove that they do
>>    not hurt when unconfigured (they are theoretically no-op while
>>    being opt-in, but we want to make sure), and that they do help
>>    when configured.  And then once we are satisfied, the default
>>    flip can be discussed and applied.
>
> Thinking about this a bit more, I see a strong reason to prefer the
> way the series in this iteration is constructed.  We could merge the
> early parts down to 'next' well before the last piece, and hopefully
> we will know how much what they are already using breaks (and we
> know colors are use in the field, and we know by default we pass
> colors, so this is to catch other uses of control sequences) by
> filtering among those who are running 'next' for their every-day
> work, before the main part of the series leaves 'master'.
>
> If we did it the other way around, even if we mergee everything to
> 'next', the guinea-pig population will be limited to those who build
> 'next' with WITH_BREAKING_CHANGES, which would be a lot smaller
> minority (I suspect that nobody uses a build with
> WITH_BREAKING_CHANGES for their every-day work, actually).
>
> So I no longer think the "no-op by default first and then tighten at
> the end with WITH_BREAKING_CHANGES" is my preference.

The other two points I still care about.

Others have any opinion on the topic?

[PATCH 0/3] Sanitizing sideband output

[Junio C Hamano]

The topic has been waiting for an action but haven't seen any.  Here
is a follow-up message in an attempt to unblock.

>> Users who need different behavior get configuration options:
>> sideband.allowControlCharacters provides an escape hatch for environments
>> that require raw passthrough. The defaults in Git v3.0 will be secure.
>>
>> This series applies cleanly on v2.53.0.
>
> Thanks for an updated series.  They applied cleanly and merged
> cleanly to 'seen'.

> I have three problems with this round, some minor, some fundamental.

... among which I already retracted one.

>  * There is a value "default" that the user can use to configure it,
>    which changes its behaviour across Git 3.0 version boundary.  I
>    think this is a horrible design.  Those who do not configure may
>    be showing their acceptance "I can go with whatever the tool's
>    designers choose with the option, and if that changes in the
>    middle, I can adapt", but for those who do, the configuration is
>    a mechanism, an escape hatch, to express their preference and
>    avoid getting disrupted by future change of behaviour.
>
>    Fixing it is easy here; just remove "default".  Those who want to
>    live in the fiture earlycan set it to "color" and it will stay
>    valid across Git 3.0 version boundary.  Those who want to make
>    sure their control sequences won't be broken can set it to "pass
>    everything" and it will stay valid across Git 3.0 version
>    boundary.

The patch [1/3] in this series addresses this issue.  This is to be
applied on top of Dscho's [5/6].

>  * I would have preferred to see the early parts of the series all
>    being opt-in, and that subset of the series be able to graduate
>    earlier.  Way earlier than the default flip to prove that they do
>    not hurt when unconfigured (they are theoretically no-op while
>    being opt-in, but we want to make sure), and that they do help
>    when configured.  And then once we are satisfied, the default
>    flip can be discussed and applied.

This is what I already retracted.  The structure of the posted
series to start extra tight and then tighten the default with the
last patch is actually good for experiment.  We can merge all the
steps without the "Loosen until Git 3.0 and then tighten Git 3.0
with WITH_BREAKING_CHANGES option" patch to 'next' and see who
screams.  Once it proves to be not too bad, we can then merge that
last step also to 'next' and make sure the loosened state still
works as expected.

So, the plan is to merge the early part of the series, INCLUDING the
"do not introduce the value 'default' that will change its meaning
in the configuration file" step, to 'next', while holding the last
"Loosen until Git 3.0" step back.  The last step in Dscho's series
[6/6] has to be adjusted because of minor textual conflicts with the
"do not introduce the value 'default'" step, so a rebased version of
it appears as [2/3] in this series.

>  * The overall approach is "we know better than our users what
>    control sequences we want to pass, so we will write code to
>    recognize these small number of control sequences and allow
>    them", which I am worried that would put more users at risk.
>
>    But the thing is that our code may not know better than the users
>    what control sequences, which have little security implications,
>    users want to use in the payload between their servers and their
>    desktop clients.  What happens to these users who use the control
>    sequences that the code does not recognize and still want to keep
>    using them?  They have to either
>
>      (1) write code to teach git to recognize their control
>          sequences (perhaps they do want ISO/IEC 2022 passed) and
>          tweak the allowlist mechanism to support it, or
>
>      (2) use the allowlist mechanism to pass everything, even the
>          sequences they are not interested in passing that have
>          security implications.
>
>    Most of them I suspect will do the latter, which is not what we
>    want to see.
>
>    Can't we do this the other way around?  The code may not be able
>    to know what control sequences the users may want to use better
>    than the users, but the code (and the author of the code) should
>    know what control sequences have negative security implications
>    much better than the users.  Instead of teaching the code to
>    recognize control sequences to color strings [*} that have little
>    security implications, can we teach the code to recognise control
>    sequences that we do *not* want to pass and neuter them, without
>    molesting control sequences with little security implications
>    that users may want to use?

And I cannot do this part myself, as the posted series does not shed
any light what uncertainty we fear in the bytestream coming from the
other side.  If we know what malicious data we want to protect
against, we can surgically and specifically protect against them,
but there is no hint in the posted series X-<.


Summary of patches in this series:

 * [1/3] sideband: drop 'default' configuration

   Remove the value 'default' from the allowed values for the
   sideband.allowControlCharacters configuration variable.  Applies
   on top of Dscho's [5/6].

 * [2/3] sideband: delay sanitizing by default to Git v3.0

   Dscho's [6/6] rebased on top of [1/3] of this series.

 * [3/3] sideband: conditional documentation fix

   Documentation mark-up update to help translators with the
   conditional documentation added in [2/3].


 Documentation/config/sideband.adoc  | 13 ++++++++++---
 sideband.c                          | 10 ++++++----
 t/t5409-colorize-remote-messages.sh | 18 +++++++++++++-----
 3 files changed, 29 insertions(+), 12 deletions(-)

-- 
2.53.0-549-g863838a955

[PATCH 1/3] sideband: drop 'default' configuration

[Junio C Hamano]

The topic so far allows users to tweak the configuration variable
sideband.allowControlCharacters to override the hardcoded default,
but among which there is the value called 'default'.  The plan [*]
of the series is to loosen the setting by a later commit in the
series and schedule it to tighten at the Git 3.0 boundary for end
users, and the meaning of this 'default' value will change.

Which has to be called a horrible design.  A user expresses their
preference by setting configuration variable in order to guard
against sudden change brought in by changes to the hardcoded default
behaviour, and letting them set it to 'default' that will change at
the Git 3.0 boundary completely defeats its purpose.  If a user
wants to say "I am easy and can go with whatever hardcoded default
Git implementors choose for me", they simply leave the configuration
variable unspecified.

Let's remove it from the state before Git 3.0 so that those users
who set it to 'default' will not see the behaviour changed under
their feet all of a sudden.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc | 1 -
 sideband.c                         | 6 ++----
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 32088bbf2f..96fade7f5f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -6,7 +6,6 @@ sideband.allowControlCharacters::
 	a comma-separated list of the following keywords):
 +
 --
-	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
diff --git a/sideband.c b/sideband.c
index a90db9e288..04282a568e 100644
--- a/sideband.c
+++ b/sideband.c
@@ -33,8 +33,8 @@ static enum {
 	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
 	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
 	ALLOW_ANSI_ERASE              = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
 	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES
 } allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
@@ -62,9 +62,7 @@ int sideband_allow_control_characters_config(const char *var, const char *value)
 
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
-		if (skip_prefix_in_csv(value, "default", &value))
-			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (skip_prefix_in_csv(value, "color", &value))
+		if (skip_prefix_in_csv(value, "color", &value))
 			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
 		else if (skip_prefix_in_csv(value, "cursor", &value))
 			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
-- 
2.53.0-549-g863838a955

[PATCH 2/3] sideband: delay sanitizing by default to Git v3.0

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The sideband sanitization patches allow ANSI color sequences through
by default, preserving compatibility with pre-receive hooks that
provide colored output during `git push`.

Even so, there is concern that changing any default behavior in a
minor release may have unforeseen consequences. To accommodate this,
defer the secure-by-default behavior to Git v3.0, where breaking
changes are expected.

This gives users and tooling time to prepare, while committing to
address CVE-2024-52005 in Git v3.0.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jc: adjusted for the removal of 'default' value]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc  |  7 +++++++
 sideband.c                          |  6 +++++-
 t/t5409-colorize-remote-messages.sh | 18 +++++++++++++-----
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 96fade7f5f..85205477b7 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -1,6 +1,13 @@
 sideband.allowControlCharacters::
+ifdef::with-breaking-changes[]
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
+endif::with-breaking-changes[]
+ifndef::with-breaking-changes[]
+	By default, no control characters delivered via the sideband
+	are masked. This is unsafe and will change in Git v3.* to only
+	allow ANSI color sequences by default, preventing potentially
+endif::with-breaking-changes[]
 	unwanted ANSI escape sequences from being sent to the terminal. Use
 	this config setting to override this behavior (the value can be
 	a comma-separated list of the following keywords):
diff --git a/sideband.c b/sideband.c
index 04282a568e..5fb60e52bf 100644
--- a/sideband.c
+++ b/sideband.c
@@ -34,7 +34,11 @@ static enum {
 	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
 	ALLOW_ANSI_ERASE              = 1<<2,
 	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
-	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES
+#ifdef WITH_BREAKING_CHANGES
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+#else
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ALL_CONTROL_CHARACTERS,
+#endif
 } allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 3010913bb1..07cbc62736 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -98,6 +98,13 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+if test_have_prereq WITH_BREAKING_CHANGES
+then
+	TURN_ON_SANITIZING=already.turned=on
+else
+	TURN_ON_SANITIZING=sideband.allowControlCharacters=color
+fi
+
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
@@ -106,7 +113,7 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
 
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
 	test_grep RED decoded &&
 	test_grep "\\^G" stderr &&
@@ -138,7 +145,7 @@ test_decode_csi() {
 	}'
 }
 
-test_expect_success 'control sequences in sideband allowed by default' '
+test_expect_success 'control sequences in sideband allowed by default (in Git v3.8)' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
 	exec "$@"
@@ -147,7 +154,7 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_commit need-at-least-one-commit-at-least &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
@@ -175,14 +182,15 @@ test_expect_success 'allow all control sequences for a specific URL' '
 	test_commit one-more-please &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
 	test_grep "\\^\\[\\[K" decoded &&
 
 	rm -rf throw-away &&
-	git -c "sideband.file://.allowControlCharacters=true" \
+	git -c sideband.allowControlCharacters=false \
+		-c "sideband.file://.allowControlCharacters=true" \
 		clone --no-local "file://$PWD" throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
-- 
2.53.0-549-g863838a955

[PATCH 3/3] sideband: conditional documentation fix

[Junio C Hamano]

Duplicate a bit of text on either side of the ifdef/ifndef
conditional documentation in order to avoid "sentence assembly" that
does not fit well with translations, taking hint from the discussion
on a recent topic.

cf. https://lore.kernel.org/git/ff86f877-4b75-403d-a5a4-10ab528a9691@free.fr/

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 85205477b7..ddba93393c 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -2,14 +2,15 @@ sideband.allowControlCharacters::
 ifdef::with-breaking-changes[]
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal.
 endif::with-breaking-changes[]
 ifndef::with-breaking-changes[]
 	By default, no control characters delivered via the sideband
 	are masked. This is unsafe and will change in Git v3.* to only
 	allow ANSI color sequences by default, preventing potentially
+	unwanted ANSI escape sequences from being sent to the terminal.
 endif::with-breaking-changes[]
-	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior (the value can be
+	Use this config setting to override this behavior (the value can be
 	a comma-separated list of the following keywords):
 +
 --
-- 
2.53.0-549-g863838a955

[PATCH v5 0/7] Sanitizing sideband output

[Junio C Hamano]

Git's sideband channel passes server output directly to the client
terminal without sanitizing it, creating an ANSI escape sequence
injection vulnerability.  A patchset was posted based on the "we
dictate what byte sequences are allowed to be used by the end user,
and reject everything else, but the users can choose to lift the
blanket rejection" approach, found in [*1*], but the discussion
stalled.

Here is an attempt to unblock the topic.  In this round, the series
keeps the "we know what users are allowed to use and reject the
rest" approach from the original, but fixes one design problem
around the configuration variable.  The value 'default' that can be
explicitly set to the configuration whose meaning is planned to
change across Git 3.0 boundary is now gone.

The series is structured as follows.

 * The first 5 patches are from Dscho's [v4 1-5/6].  These introduce
   "reject what we do not explicitly allow" framework, and by
   default allow only ANSI color escape sequences.

   [1/7] sideband: mask control characters
   [2/7] sideband: introduce an "escape hatch" to allow control characters
   [3/7] sideband: do allow ANSI color sequences by default
   [4/7] sideband: add options to allow more control sequences to be passed through
   [5/7] sideband: offer to configure sanitizing on a per-URL basis

 * The 'default' problem was raised in [*2*] and the 6th patch is
   about solving it.

   [6/7] sideband: drop 'default' configuration

 * The 7th patch is from Dscho's [v4 6/6], adjusted for the above
   step.  This loosens the rules to allow _everything_ (i.e., the
   same as before) before Git 3.0, and then rejects anything other
   than ANSI color escape sequences after Git 3.0

   [7/7] sideband: delay sanitizing by default to Git v3.0

I think without the 'default' that changes its meaning across
version boundary, the early part of the series is a good place to
stop, if we want to proceed with the "allowlist" approach.  Unless I
hear objections, let's plan to merge patches 1-6 (i.e., everything
other than ANSI color escape sequences are filtered out) to 'next'
and keep it there for some time, to see if anybody screams, without
the last patch.

I am still hoping that people can help the topic and make it less
risky for users who are affected by switching to an opposite
philosophy, namely, "we filter byte sequences that are known to us
to be problematic, and pass everything else intact", but that is a
separate topic [*2*].  The experiment with patches 1-6 cooked in
'next' long enough may convince ourselves that ANSI colors are the
only thing that needs passing (which I personally fear is a bit too
naïve but we will never know until we try).


[References]

 *1* https://lore.kernel.org/git/pull.1853.v4.git.1770113882.gitgitgadget@gmail.com/

 *2* https://lore.kernel.org/git/xmqqv7gcnwd4.fsf@gitster.g/

-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 1/7] sideband: mask control characters

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The output of `git clone` is a vital component for understanding what
has happened when things go wrong. However, these logs are partially
under the control of the remote server (via the "sideband", which
typically contains what the remote `git pack-objects` process sends to
`stderr`), and is currently not sanitized by Git.

This makes Git susceptible to ANSI escape sequence injection (see
CWE-150, https://cwe.mitre.org/data/definitions/150.html), which allows
attackers to corrupt terminal state, to hide information, and even to
insert characters into the input buffer (i.e. as if the user had typed
those characters).

To plug this vulnerability, disallow any control character in the
sideband, replacing them instead with the common `^<letter/symbol>`
(e.g. `^[` for `\x1b`, `^A` for `\x01`).

There is likely a need for more fine-grained controls instead of using a
"heavy hammer" like this, which will be introduced subsequently.

Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 sideband.c                          | 17 +++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 12 ++++++++++++
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/sideband.c b/sideband.c
index ea7c25211e..c1bbadccac 100644
--- a/sideband.c
+++ b/sideband.c
@@ -66,6 +66,19 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
+{
+	strbuf_grow(dest, n);
+	for (; n && *src; src++, n--) {
+		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
+			strbuf_addch(dest, *src);
+		} else {
+			strbuf_addch(dest, '^');
+			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
+		}
+	}
+}
+
 /*
  * Optionally highlight one keyword in remote output if it appears at the start
  * of the line. This should be called for a single line only, which is
@@ -81,7 +94,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 	int i;
 
 	if (!want_color_stderr(use_sideband_colors())) {
-		strbuf_add(dest, src, n);
+		strbuf_add_sanitized(dest, src, n);
 		return;
 	}
 
@@ -114,7 +127,7 @@ static void maybe_colorize_sideband(struct strbuf *dest, const char *src, int n)
 		}
 	}
 
-	strbuf_add(dest, src, n);
+	strbuf_add_sanitized(dest, src, n);
 }
 
 
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index fa5de4500a..aa5b570571 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -98,4 +98,16 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+test_expect_success 'disallow (color) control sequences in sideband' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep ! RED decoded
+'
+
 test_done
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 2/7] sideband: introduce an "escape hatch" to allow control characters

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding commit fixed the vulnerability whereas sideband messages
(that are under the control of the remote server) could contain ANSI
escape sequences that would be sent to the terminal verbatim.

However, this fix may not be desirable under all circumstances, e.g.
when remote servers deliberately add coloring to their messages to
increase their urgency.

To help with those use cases, give users a way to opt-out of the
protections: `sideband.allowControlCharacters`.

Suggested-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config.adoc           |  2 ++
 Documentation/config/sideband.adoc  |  5 +++++
 sideband.c                          | 10 ++++++++++
 t/t5409-colorize-remote-messages.sh |  8 +++++++-
 4 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/config/sideband.adoc

diff --git a/Documentation/config.adoc b/Documentation/config.adoc
index 62eebe7c54..dcea3c0c15 100644
--- a/Documentation/config.adoc
+++ b/Documentation/config.adoc
@@ -523,6 +523,8 @@ include::config/sequencer.adoc[]
 
 include::config/showbranch.adoc[]
 
+include::config/sideband.adoc[]
+
 include::config/sparse.adoc[]
 
 include::config/splitindex.adoc[]
diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
new file mode 100644
index 0000000000..3fb5045cd7
--- /dev/null
+++ b/Documentation/config/sideband.adoc
@@ -0,0 +1,5 @@
+sideband.allowControlCharacters::
+	By default, control characters that are delivered via the sideband
+	are masked, to prevent potentially unwanted ANSI escape sequences
+	from being sent to the terminal. Use this config setting to override
+	this behavior.
diff --git a/sideband.c b/sideband.c
index c1bbadccac..682f1cbbed 100644
--- a/sideband.c
+++ b/sideband.c
@@ -26,6 +26,8 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
+static int allow_control_characters;
+
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
 {
@@ -39,6 +41,9 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
+	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
+			    &allow_control_characters);
+
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
 	else if (!repo_config_get_string_tmp(the_repository, "color.ui", &value))
@@ -68,6 +73,11 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
+	if (allow_control_characters) {
+		strbuf_add(dest, src, n);
+		return;
+	}
+
 	strbuf_grow(dest, n);
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index aa5b570571..9caee9a07f 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -105,9 +105,15 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
+
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep ! RED decoded
+	test_grep ! RED decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
+	test_grep RED decoded
 '
 
 test_done
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 3/7] sideband: do allow ANSI color sequences by default

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The preceding two commits introduced special handling of the sideband
channel to neutralize ANSI escape sequences before sending the payload
to the terminal, and `sideband.allowControlCharacters` to override that
behavior.

However, as reported by brian m. carlson, some `pre-receive` hooks that
are actively used in practice want to color their messages and therefore
rely on the fact that Git passes them through to the terminal, even
though they have no way to determine whether the receiving side can
actually handle Escape sequences (think e.g. about the practice
recommended by Git that third-party applications wishing to use Git
functionality parse the output of Git commands).

In contrast to other ANSI escape sequences, it is highly unlikely that
coloring sequences can be essential tools in attack vectors that mislead
Git users e.g. by hiding crucial information.

Therefore we can have both: Continue to allow ANSI coloring sequences to
be passed to the terminal by default, and neutralize all other ANSI
Escape sequences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc  | 18 ++++++--
 sideband.c                          | 66 +++++++++++++++++++++++++++--
 t/t5409-colorize-remote-messages.sh | 16 ++++++-
 3 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 3fb5045cd7..b55c73726f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -1,5 +1,17 @@
 sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
-	are masked, to prevent potentially unwanted ANSI escape sequences
-	from being sent to the terminal. Use this config setting to override
-	this behavior.
+	are masked, except ANSI color sequences. This prevents potentially
+	unwanted ANSI escape sequences from being sent to the terminal. Use
+	this config setting to override this behavior:
++
+--
+	`default`::
+	`color`::
+		Allow ANSI color sequences, line feeds and horizontal tabs,
+		but mask all other control characters. This is the default.
+	`false`::
+		Mask all control characters other than line feeds and
+		horizontal tabs.
+	`true`::
+		Allow all control characters to be sent to the terminal.
+--
diff --git a/sideband.c b/sideband.c
index 682f1cbbed..eeba6fa2ca 100644
--- a/sideband.c
+++ b/sideband.c
@@ -26,7 +26,12 @@ static struct keyword_entry keywords[] = {
 	{ "error",	GIT_COLOR_BOLD_RED },
 };
 
-static int allow_control_characters;
+static enum {
+	ALLOW_NO_CONTROL_CHARACTERS  = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
+} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
@@ -41,8 +46,26 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
-	repo_config_get_bool(the_repository, "sideband.allowcontrolcharacters",
-			    &allow_control_characters);
+	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
+	case 0: /* Boolean value */
+		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
+			ALLOW_NO_CONTROL_CHARACTERS;
+		break;
+	case -1: /* non-Boolean value */
+		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
+					      &value))
+			; /* huh? `get_maybe_bool()` returned -1 */
+		else if (!strcmp(value, "default"))
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (!strcmp(value, "color"))
+			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+		break;
+	default:
+		break; /* not configured */
+	}
 
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
 		use_sideband_colors_cached = git_config_colorbool(key, value);
@@ -71,9 +94,41 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
+static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+{
+	int i;
+
+	/*
+	 * Valid ANSI color sequences are of the form
+	 *
+	 * ESC [ [<n> [; <n>]*] m
+	 *
+	 * These are part of the Select Graphic Rendition sequences which
+	 * contain more than just color sequences, for more details see
+	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 */
+
+	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
+	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+		return 0;
+
+	for (i = 2; i < n; i++) {
+		if (src[i] == 'm') {
+			strbuf_add(dest, src, i + 1);
+			return i;
+		}
+		if (!isdigit(src[i]) && src[i] != ';')
+			break;
+	}
+
+	return 0;
+}
+
 static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
-	if (allow_control_characters) {
+	int i;
+
+	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -82,6 +137,9 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
+		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+			src += i;
+			n -= i;
 		} else {
 			strbuf_addch(dest, '^');
 			strbuf_addch(dest, *src == 0x7f ? '?' : 0x40 + *src);
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 9caee9a07f..e5092d3b42 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -100,7 +100,7 @@ test_expect_success 'fallback to color.ui' '
 
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
-	printf "error: Have you \\033[31mread\\033[m this?\\n" >&2
+	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
 	exec "$@"
 	EOF
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
@@ -108,12 +108,24 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 
 	git clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
+	test_grep RED decoded &&
+	test_grep "\\^G" stderr &&
+	tr -dc "\\007" <stderr >actual &&
+	test_must_be_empty actual &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=false \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >decoded &&
 	test_grep ! RED decoded &&
+	test_grep "\\^G" stderr &&
 
 	rm -rf throw-away &&
 	git -c sideband.allowControlCharacters clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
-	test_grep RED decoded
+	test_grep RED decoded &&
+	tr -dc "\\007" <stderr >actual &&
+	test_file_not_empty actual
 '
 
 test_done
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 4/7] sideband: add options to allow more control sequences to be passed through

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Even though control sequences that erase characters are quite juicy for
attack scenarios, where attackers are eager to hide traces of suspicious
activities, during the review of the side band sanitizing patch series
concerns were raised that there might be some legimitate scenarios where
Git server's `pre-receive` hooks use those sequences in a benign way.

Control sequences to move the cursor can likewise be used to hide tracks
by overwriting characters, and have been equally pointed out as having
legitimate users.

Let's add options to let users opt into passing through those ANSI
Escape sequences: `sideband.allowControlCharacters` now supports also
`cursor` and `erase`, and it parses the value as a comma-separated list.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc  |  9 ++-
 sideband.c                          | 91 ++++++++++++++++++++++++-----
 t/t5409-colorize-remote-messages.sh | 38 ++++++++++++
 3 files changed, 123 insertions(+), 15 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index b55c73726f..2bf0426284 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -2,13 +2,20 @@ sideband.allowControlCharacters::
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
 	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior:
+	this config setting to override this behavior (the value can be
+	a comma-separated list of the following keywords):
 +
 --
 	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
+	`cursor:`:
+		Allow control sequences that move the cursor. This is
+		disabled by default.
+	`erase`::
+		Allow control sequences that erase charactrs. This is
+		disabled by default.
 	`false`::
 		Mask all control characters other than line feeds and
 		horizontal tabs.
diff --git a/sideband.c b/sideband.c
index eeba6fa2ca..0b420ca319 100644
--- a/sideband.c
+++ b/sideband.c
@@ -29,9 +29,43 @@ static struct keyword_entry keywords[] = {
 static enum {
 	ALLOW_NO_CONTROL_CHARACTERS  = 0,
 	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
+	ALLOW_ANSI_ERASE             = 1<<2,
 	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<1,
-} allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
+	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
+} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+
+static inline int skip_prefix_in_csv(const char *value, const char *prefix,
+				     const char **out)
+{
+	if (!skip_prefix(value, prefix, &value) ||
+	    (*value && *value != ','))
+		return 0;
+	*out = value + !!*value;
+	return 1;
+}
+
+static void parse_allow_control_characters(const char *value)
+{
+	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+	while (*value) {
+		if (skip_prefix_in_csv(value, "default", &value))
+			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "color", &value))
+			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
+		else if (skip_prefix_in_csv(value, "cursor", &value))
+			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
+		else if (skip_prefix_in_csv(value, "erase", &value))
+			allow_control_characters |= ALLOW_ANSI_ERASE;
+		else if (skip_prefix_in_csv(value, "true", &value))
+			allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		else if (skip_prefix_in_csv(value, "false", &value))
+			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		else
+			warning(_("unrecognized value for `sideband."
+				  "allowControlCharacters`: '%s'"), value);
+	}
+}
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
 static enum git_colorbool use_sideband_colors(void)
@@ -55,13 +89,8 @@ static enum git_colorbool use_sideband_colors(void)
 		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
 					      &value))
 			; /* huh? `get_maybe_bool()` returned -1 */
-		else if (!strcmp(value, "default"))
-			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (!strcmp(value, "color"))
-			allow_control_characters = ALLOW_ANSI_COLOR_SEQUENCES;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			parse_allow_control_characters(value);
 		break;
 	default:
 		break; /* not configured */
@@ -94,7 +123,7 @@ void list_config_color_sideband_slots(struct string_list *list, const char *pref
 		list_config_item(list, prefix, keywords[i].keyword);
 }
 
-static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int n)
+static int handle_ansi_sequence(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
@@ -106,14 +135,47 @@ static int handle_ansi_color_sequence(struct strbuf *dest, const char *src, int
 	 * These are part of the Select Graphic Rendition sequences which
 	 * contain more than just color sequences, for more details see
 	 * https://en.wikipedia.org/wiki/ANSI_escape_code#SGR.
+	 *
+	 * The cursor movement sequences are:
+	 *
+	 * ESC [ n A - Cursor up n lines (CUU)
+	 * ESC [ n B - Cursor down n lines (CUD)
+	 * ESC [ n C - Cursor forward n columns (CUF)
+	 * ESC [ n D - Cursor back n columns (CUB)
+	 * ESC [ n E - Cursor next line, beginning (CNL)
+	 * ESC [ n F - Cursor previous line, beginning (CPL)
+	 * ESC [ n G - Cursor to column n (CHA)
+	 * ESC [ n ; m H - Cursor position (row n, col m) (CUP)
+	 * ESC [ n ; m f - Same as H (HVP)
+	 *
+	 * The sequences to erase characters are:
+	 *
+	 *
+	 * ESC [ 0 J - Clear from cursor to end of screen (ED)
+	 * ESC [ 1 J - Clear from cursor to beginning of screen (ED)
+	 * ESC [ 2 J - Clear entire screen (ED)
+	 * ESC [ 3 J - Clear entire screen + scrollback (ED) - xterm extension
+	 * ESC [ 0 K - Clear from cursor to end of line (EL)
+	 * ESC [ 1 K - Clear from cursor to beginning of line (EL)
+	 * ESC [ 2 K - Clear entire line (EL)
+	 * ESC [ n M - Delete n lines (DL)
+	 * ESC [ n P - Delete n characters (DCH)
+	 * ESC [ n X - Erase n characters (ECH)
+	 *
+	 * For a comprehensive list of common ANSI Escape sequences, see
+	 * https://www.xfree86.org/current/ctlseqs.html
 	 */
 
-	if (allow_control_characters != ALLOW_ANSI_COLOR_SEQUENCES ||
-	    n < 3 || src[0] != '\x1b' || src[1] != '[')
+	if (n < 3 || src[0] != '\x1b' || src[1] != '[')
 		return 0;
 
 	for (i = 2; i < n; i++) {
-		if (src[i] == 'm') {
+		if (((allow_control_characters & ALLOW_ANSI_COLOR_SEQUENCES) &&
+		     src[i] == 'm') ||
+		    ((allow_control_characters & ALLOW_ANSI_CURSOR_MOVEMENTS) &&
+		     strchr("ABCDEFGHf", src[i])) ||
+		    ((allow_control_characters & ALLOW_ANSI_ERASE) &&
+		     strchr("JKMPX", src[i]))) {
 			strbuf_add(dest, src, i + 1);
 			return i;
 		}
@@ -128,7 +190,7 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 {
 	int i;
 
-	if (allow_control_characters == ALLOW_ALL_CONTROL_CHARACTERS) {
+	if ((allow_control_characters & ALLOW_ALL_CONTROL_CHARACTERS)) {
 		strbuf_add(dest, src, n);
 		return;
 	}
@@ -137,7 +199,8 @@ static void strbuf_add_sanitized(struct strbuf *dest, const char *src, int n)
 	for (; n && *src; src++, n--) {
 		if (!iscntrl(*src) || *src == '\t' || *src == '\n') {
 			strbuf_addch(dest, *src);
-		} else if ((i = handle_ansi_color_sequence(dest, src, n))) {
+		} else if (allow_control_characters != ALLOW_NO_CONTROL_CHARACTERS &&
+			   (i = handle_ansi_sequence(dest, src, n))) {
 			src += i;
 			n -= i;
 		} else {
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index e5092d3b42..896e790bf9 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -128,4 +128,42 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_file_not_empty actual
 '
 
+test_decode_csi() {
+	awk '{
+		while (match($0, /\033/) != 0) {
+			printf "%sCSI ", substr($0, 1, RSTART-1);
+			$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
+		}
+		print
+	}'
+}
+
+test_expect_success 'control sequences in sideband allowed by default' '
+	write_script .git/color-me-surprised <<-\EOF &&
+	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
+	test_commit need-at-least-one-commit-at-least &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep ! "CSI \\[G" decoded &&
+	test_grep "\\^\\[?25l" decoded &&
+
+	rm -rf throw-away &&
+	git -c sideband.allowControlCharacters=erase,cursor,color \
+		clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "RED" decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep "CSI \\[G" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded &&
+	test_grep ! "\\^\\[\\[G" decoded
+'
+
 test_done
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 5/7] sideband: offer to configure sanitizing on a per-URL basis

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The main objection against sanitizing the sideband that was raised
during the review of the sideband sanitizing patches, first on the
git-security mailing list, then on the public mailing list, was that
there are some setups where server-side `pre-receive` hooks want to
error out, giving colorful messages to the users on the client side (if
they are not redirecting the output into a file, that is).

To avoid breaking such setups, the default chosen by the sideband
sanitizing patches is to pass through ANSI color sequences.

Still, there might be some use case out there where that is not enough.
Therefore the `sideband.allowControlCharacters` config setting allows
for configuring  levels of sanitizing.

As Junio Hamano pointed out, to keep users safe by default, we need to
be able to scope this to some servers because while a user may trust
their company's Git server, the same might not apply to other Git
servers.

To allow for this, let's imitate the way `http.<url>.*` offers
to scope config settings to certain URLs, by letting users
override the `sideband.allowControlCharacters` setting via
`sideband.<url>.allowControlCharacters`.

Suggested-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc  |  4 ++
 sideband.c                          | 81 ++++++++++++++++++++---------
 sideband.h                          | 14 +++++
 t/t5409-colorize-remote-messages.sh | 24 +++++++++
 transport.c                         |  3 ++
 5 files changed, 102 insertions(+), 24 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 2bf0426284..32088bbf2f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -22,3 +22,7 @@ sideband.allowControlCharacters::
 	`true`::
 		Allow all control characters to be sent to the terminal.
 --
+
+sideband.<url>.*::
+	Apply the `sideband.*` option selectively to specific URLs. The
+	same URL matching logic applies as for `http.<url>.*` settings.
diff --git a/sideband.c b/sideband.c
index 0b420ca319..a90db9e288 100644
--- a/sideband.c
+++ b/sideband.c
@@ -10,6 +10,7 @@
 #include "help.h"
 #include "pkt-line.h"
 #include "write-or-die.h"
+#include "urlmatch.h"
 
 struct keyword_entry {
 	/*
@@ -27,13 +28,14 @@ static struct keyword_entry keywords[] = {
 };
 
 static enum {
-	ALLOW_NO_CONTROL_CHARACTERS  = 0,
-	ALLOW_ANSI_COLOR_SEQUENCES   = 1<<0,
-	ALLOW_ANSI_CURSOR_MOVEMENTS  = 1<<1,
-	ALLOW_ANSI_ERASE             = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES = ALLOW_ANSI_COLOR_SEQUENCES,
-	ALLOW_ALL_CONTROL_CHARACTERS = 1<<3,
-} allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
+	ALLOW_CONTROL_SEQUENCES_UNSET = -1,
+	ALLOW_NO_CONTROL_CHARACTERS   = 0,
+	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
+	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
+	ALLOW_ANSI_ERASE              = 1<<2,
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+} allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 				     const char **out)
@@ -45,8 +47,19 @@ static inline int skip_prefix_in_csv(const char *value, const char *prefix,
 	return 1;
 }
 
-static void parse_allow_control_characters(const char *value)
+int sideband_allow_control_characters_config(const char *var, const char *value)
 {
+	switch (git_parse_maybe_bool(value)) {
+	case 0:
+		allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
+		return 0;
+	case 1:
+		allow_control_characters = ALLOW_ALL_CONTROL_CHARACTERS;
+		return 0;
+	default:
+		break;
+	}
+
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
 		if (skip_prefix_in_csv(value, "default", &value))
@@ -62,9 +75,37 @@ static void parse_allow_control_characters(const char *value)
 		else if (skip_prefix_in_csv(value, "false", &value))
 			allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 		else
-			warning(_("unrecognized value for `sideband."
-				  "allowControlCharacters`: '%s'"), value);
+			warning(_("unrecognized value for '%s': '%s'"), var, value);
 	}
+	return 0;
+}
+
+static int sideband_config_callback(const char *var, const char *value,
+				    const struct config_context *ctx UNUSED,
+				    void *data UNUSED)
+{
+	if (!strcmp(var, "sideband.allowcontrolcharacters"))
+		return sideband_allow_control_characters_config(var, value);
+
+	return 0;
+}
+
+void sideband_apply_url_config(const char *url)
+{
+	struct urlmatch_config config = URLMATCH_CONFIG_INIT;
+	char *normalized_url;
+
+	if (!url)
+		BUG("must not call sideband_apply_url_config(NULL)");
+
+	config.section = "sideband";
+	config.collect_fn = sideband_config_callback;
+
+	normalized_url = url_normalize(url, &config.url);
+	repo_config(the_repository, urlmatch_config_entry, &config);
+	free(normalized_url);
+	string_list_clear(&config.vars, 1);
+	urlmatch_config_release(&config);
 }
 
 /* Returns a color setting (GIT_COLOR_NEVER, etc). */
@@ -80,20 +121,12 @@ static enum git_colorbool use_sideband_colors(void)
 	if (use_sideband_colors_cached != GIT_COLOR_UNKNOWN)
 		return use_sideband_colors_cached;
 
-	switch (repo_config_get_maybe_bool(the_repository, "sideband.allowcontrolcharacters", &i)) {
-	case 0: /* Boolean value */
-		allow_control_characters = i ? ALLOW_ALL_CONTROL_CHARACTERS :
-			ALLOW_NO_CONTROL_CHARACTERS;
-		break;
-	case -1: /* non-Boolean value */
-		if (repo_config_get_string_tmp(the_repository, "sideband.allowcontrolcharacters",
-					      &value))
-			; /* huh? `get_maybe_bool()` returned -1 */
-		else
-			parse_allow_control_characters(value);
-		break;
-	default:
-		break; /* not configured */
+	if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET) {
+		if (!repo_config_get_value(the_repository, "sideband.allowcontrolcharacters", &value))
+			sideband_allow_control_characters_config("sideband.allowcontrolcharacters", value);
+
+		if (allow_control_characters == ALLOW_CONTROL_SEQUENCES_UNSET)
+			allow_control_characters = ALLOW_DEFAULT_ANSI_SEQUENCES;
 	}
 
 	if (!repo_config_get_string_tmp(the_repository, key, &value))
diff --git a/sideband.h b/sideband.h
index 5a25331be5..d15fa4015f 100644
--- a/sideband.h
+++ b/sideband.h
@@ -30,4 +30,18 @@ int demultiplex_sideband(const char *me, int status,
 
 void send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
 
+/*
+ * Apply sideband configuration for the given URL. This should be called
+ * when a transport is created to allow URL-specific configuration of
+ * sideband behavior (e.g., sideband.<url>.allowControlCharacters).
+ */
+void sideband_apply_url_config(const char *url);
+
+/*
+ * Parse and set the sideband allow control characters configuration.
+ * The var parameter should be the key name (without section prefix).
+ * Returns 0 if the variable was recognized and handled, non-zero otherwise.
+ */
+int sideband_allow_control_characters_config(const char *var, const char *value);
+
 #endif
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 896e790bf9..3010913bb1 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -166,4 +166,28 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_grep ! "\\^\\[\\[G" decoded
 '
 
+test_expect_success 'allow all control sequences for a specific URL' '
+	write_script .git/eraser <<-\EOF &&
+	printf "error: Ohai!\\r\\033[K" >&2
+	exec "$@"
+	EOF
+	test_config_global uploadPack.packObjectsHook ./eraser &&
+	test_commit one-more-please &&
+
+	rm -rf throw-away &&
+	git clone --no-local . throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep ! "CSI \\[K" decoded &&
+	test_grep "\\^\\[\\[K" decoded &&
+
+	rm -rf throw-away &&
+	git -c "sideband.file://.allowControlCharacters=true" \
+		clone --no-local "file://$PWD" throw-away 2>stderr &&
+	test_decode_color <stderr >color-decoded &&
+	test_decode_csi <color-decoded >decoded &&
+	test_grep "CSI \\[K" decoded &&
+	test_grep ! "\\^\\[\\[K" decoded
+'
+
 test_done
diff --git a/transport.c b/transport.c
index c7f06a7382..1602065953 100644
--- a/transport.c
+++ b/transport.c
@@ -29,6 +29,7 @@
 #include "object-name.h"
 #include "color.h"
 #include "bundle-uri.h"
+#include "sideband.h"
 
 static enum git_colorbool transport_use_color = GIT_COLOR_UNKNOWN;
 static char transport_colors[][COLOR_MAXLEN] = {
@@ -1245,6 +1246,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 	ret->hash_algo = &hash_algos[GIT_HASH_SHA1_LEGACY];
 
+	sideband_apply_url_config(ret->url);
+
 	return ret;
 }
 
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 6/7] sideband: drop 'default' configuration

[Junio C Hamano]

The topic so far allows users to tweak the configuration variable
sideband.allowControlCharacters to override the hardcoded default,
but among which there is the value called 'default'.  The plan [*]
of the series is to loosen the setting by a later commit in the
series and schedule it to tighten at the Git 3.0 boundary for end
users, at which point, the meaning of this 'default' value will
change.

Which is a dubious design.

A user expresses their preference by setting configuration variable
in order to guard against sudden change brought in by changes to the
hardcoded default behaviour, and letting them set it to 'default'
that will change at the Git 3.0 boundary defeats its purpose.  If a
user wants to say "I am easy and can go with whatever hardcoded
default Git implementors choose for me", they simply leave the
configuration variable unspecified.

Let's remove it from the state before Git 3.0 so that those users
who set it to 'default' will not see the behaviour changed under
their feet all of sudden.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc | 1 -
 sideband.c                         | 6 ++----
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 32088bbf2f..96fade7f5f 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -6,7 +6,6 @@ sideband.allowControlCharacters::
 	a comma-separated list of the following keywords):
 +
 --
-	`default`::
 	`color`::
 		Allow ANSI color sequences, line feeds and horizontal tabs,
 		but mask all other control characters. This is the default.
diff --git a/sideband.c b/sideband.c
index a90db9e288..04282a568e 100644
--- a/sideband.c
+++ b/sideband.c
@@ -33,8 +33,8 @@ static enum {
 	ALLOW_ANSI_COLOR_SEQUENCES    = 1<<0,
 	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
 	ALLOW_ANSI_ERASE              = 1<<2,
-	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
 	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES
 } allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
@@ -62,9 +62,7 @@ int sideband_allow_control_characters_config(const char *var, const char *value)
 
 	allow_control_characters = ALLOW_NO_CONTROL_CHARACTERS;
 	while (*value) {
-		if (skip_prefix_in_csv(value, "default", &value))
-			allow_control_characters |= ALLOW_DEFAULT_ANSI_SEQUENCES;
-		else if (skip_prefix_in_csv(value, "color", &value))
+		if (skip_prefix_in_csv(value, "color", &value))
 			allow_control_characters |= ALLOW_ANSI_COLOR_SEQUENCES;
 		else if (skip_prefix_in_csv(value, "cursor", &value))
 			allow_control_characters |= ALLOW_ANSI_CURSOR_MOVEMENTS;
-- 
2.53.0-629-gb58d2f6a3e

[PATCH v5 7/7] sideband: delay sanitizing by default to Git v3.0

[Junio C Hamano]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

The sideband sanitization patches allow ANSI color sequences through
by default, preserving compatibility with pre-receive hooks that
provide colored output during `git push`.

Even so, there is concern that changing any default behavior in a
minor release may have unforeseen consequences. To accommodate this,
defer the secure-by-default behavior to Git v3.0, where breaking
changes are expected.

This gives users and tooling time to prepare, while committing to
address CVE-2024-52005 in Git v3.0.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jc: adjusted for the removal of 'default' value]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/config/sideband.adoc  | 12 ++++++++++--
 sideband.c                          |  6 +++++-
 t/t5409-colorize-remote-messages.sh | 18 +++++++++++++-----
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/Documentation/config/sideband.adoc b/Documentation/config/sideband.adoc
index 96fade7f5f..ddba93393c 100644
--- a/Documentation/config/sideband.adoc
+++ b/Documentation/config/sideband.adoc
@@ -1,8 +1,16 @@
 sideband.allowControlCharacters::
+ifdef::with-breaking-changes[]
 	By default, control characters that are delivered via the sideband
 	are masked, except ANSI color sequences. This prevents potentially
-	unwanted ANSI escape sequences from being sent to the terminal. Use
-	this config setting to override this behavior (the value can be
+	unwanted ANSI escape sequences from being sent to the terminal.
+endif::with-breaking-changes[]
+ifndef::with-breaking-changes[]
+	By default, no control characters delivered via the sideband
+	are masked. This is unsafe and will change in Git v3.* to only
+	allow ANSI color sequences by default, preventing potentially
+	unwanted ANSI escape sequences from being sent to the terminal.
+endif::with-breaking-changes[]
+	Use this config setting to override this behavior (the value can be
 	a comma-separated list of the following keywords):
 +
 --
diff --git a/sideband.c b/sideband.c
index 04282a568e..5fb60e52bf 100644
--- a/sideband.c
+++ b/sideband.c
@@ -34,7 +34,11 @@ static enum {
 	ALLOW_ANSI_CURSOR_MOVEMENTS   = 1<<1,
 	ALLOW_ANSI_ERASE              = 1<<2,
 	ALLOW_ALL_CONTROL_CHARACTERS  = 1<<3,
-	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES
+#ifdef WITH_BREAKING_CHANGES
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ANSI_COLOR_SEQUENCES,
+#else
+	ALLOW_DEFAULT_ANSI_SEQUENCES  = ALLOW_ALL_CONTROL_CHARACTERS,
+#endif
 } allow_control_characters = ALLOW_CONTROL_SEQUENCES_UNSET;
 
 static inline int skip_prefix_in_csv(const char *value, const char *prefix,
diff --git a/t/t5409-colorize-remote-messages.sh b/t/t5409-colorize-remote-messages.sh
index 3010913bb1..07cbc62736 100755
--- a/t/t5409-colorize-remote-messages.sh
+++ b/t/t5409-colorize-remote-messages.sh
@@ -98,6 +98,13 @@ test_expect_success 'fallback to color.ui' '
 	grep "<BOLD;RED>error<RESET>: error" decoded
 '
 
+if test_have_prereq WITH_BREAKING_CHANGES
+then
+	TURN_ON_SANITIZING=already.turned=on
+else
+	TURN_ON_SANITIZING=sideband.allowControlCharacters=color
+fi
+
 test_expect_success 'disallow (color) control sequences in sideband' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: Have you \\033[31mread\\033[m this?\\a\\n" >&2
@@ -106,7 +113,7 @@ test_expect_success 'disallow (color) control sequences in sideband' '
 	test_config_global uploadPack.packObjectsHook ./color-me-surprised &&
 	test_commit need-at-least-one-commit &&
 
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >decoded &&
 	test_grep RED decoded &&
 	test_grep "\\^G" stderr &&
@@ -138,7 +145,7 @@ test_decode_csi() {
 	}'
 }
 
-test_expect_success 'control sequences in sideband allowed by default' '
+test_expect_success 'control sequences in sideband allowed by default (in Git v3.8)' '
 	write_script .git/color-me-surprised <<-\EOF &&
 	printf "error: \\033[31mcolor\\033[m\\033[Goverwrite\\033[Gerase\\033[K\\033?25l\\n" >&2
 	exec "$@"
@@ -147,7 +154,7 @@ test_expect_success 'control sequences in sideband allowed by default' '
 	test_commit need-at-least-one-commit-at-least &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
@@ -175,14 +182,15 @@ test_expect_success 'allow all control sequences for a specific URL' '
 	test_commit one-more-please &&
 
 	rm -rf throw-away &&
-	git clone --no-local . throw-away 2>stderr &&
+	git -c $TURN_ON_SANITIZING clone --no-local . throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
 	test_grep ! "CSI \\[K" decoded &&
 	test_grep "\\^\\[\\[K" decoded &&
 
 	rm -rf throw-away &&
-	git -c "sideband.file://.allowControlCharacters=true" \
+	git -c sideband.allowControlCharacters=false \
+		-c "sideband.file://.allowControlCharacters=true" \
 		clone --no-local "file://$PWD" throw-away 2>stderr &&
 	test_decode_color <stderr >color-decoded &&
 	test_decode_csi <color-decoded >decoded &&
-- 
2.53.0-629-gb58d2f6a3e