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

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 21, 2026, 07:39 UTC
Message-ID: <aXCCqvGBl24yVgI6@pks.im>
In-Reply-To: <xmqqa4y81ag8.fsf@gitster.g>

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

Show 9 quoted lines

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

Show 20 quoted lines

> 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