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

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

"brian m. carlson" [off-list ref] writes:

quoted

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