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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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?"""
> 
>