From: D. Ben Knoble Date: Tue, 20 Jan 2026 02:41:34 GMT Subject: Re: [PATCH v2 4/4] sideband: add options to allow more control sequences to be passed through Message-ID: In-Reply-To: Forgive my self-insertion to this series… On Mon, Jan 19, 2026 at 5:16 PM brian m. carlson wrote: > > On 2026-01-19 at 07:20:41, Patrick Steinhardt wrote: > > I think what I strongly disagree with is that this is considered to be a > > feature. I myself don't consider this to be a feature though, but rather > > a security fix for a bug that can lead to arbitrary code execution on > > the client-side, for example via title bar injection. > > I don't agree with that. Nobody still enables the functionality in a > terminal that allows title bar injection. And, as I've pointed out, > even connecting to an SSH remote allows exactly the same behaviour as > this patch seems to try to fix, so there is no actual security benefit > to enabling these patches there. Defaulting this series to on is like > closing the barn door to prevent the horse from getting out when there's > a giant hole in the barn wall. > > It should be pointed out that, in general, simply using SSH to connect > to an untrusted remote system or using `cat` on an untrusted file can do > exactly the same thing as this series tries to prevent by sending > arbitrary terminal codes to the terminal. Nobody has sent patches for > SSH to make it filter out terminal sequences. It sounds like you say "There are other holes, so it doesn't make sense to try to close this one." I don't think you mean or believe that, though I don't want to put words in your mouth. I just don't find that a particularly compelling argument, especially with typical practice of the "swiss cheese" model of security. > I have also found pre-receive hooks on GitHub that will be broken by > these changes. Just because Dscho has not seen them doesn't mean that > they don't exist and many users who are not on Windows do not run the > latest Git (they run what's provided by their distro or vendor), so they > won't notice that things are broken until we've shipped the feature > being on by default. > > 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. > -- > brian m. carlson (they/them) > Toronto, Ontario, CA Cordially, -- D. Ben Knoble