From: Jeff King <peff@peff.net>
Date: Tue, 20 Jan 2026 19:31:09 GMT
Subject: Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through
Message-ID: <20260120193109.GB3295894@coredump.intra.peff.net>
In-Reply-To: <xmqqa4y81ag8.fsf@gitster.g>

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