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

[Junio C Hamano <gitster@pobox.com>]

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/