[mitchellh]

I believe it could. A shell could reduce capability by default for all executed shell scripts (file or inline on the prompt) and require opt in to not do this. Something akin to a umask of sorts. It’d break exceedingly few real scripts. (Hand waving a lot here with the “opt in” mechanism to avoid that being scripted but I have ideas)

Also note my thoughts (very much not even close to being a proposal) are very raw. Inviting this kind of discussion is exactly what I hope to do :)

Reduction of capability in general is not intended to address all class of security issue. For example you’d still want unsafe paste detection (to detect newlines or attempted bracketed paste escapes) on a prompt line.

But I think having a mechanism to eliminate the possibility of entire class of actions without wholesale disabling them in the terminal emulator is a desirable property. Right now a lot of these features are mostly on/off.

[gigatexal]

Whatever you all do please continue the fight. I love love love the ergonomics of the terminal. It feels like a super power for me and is crucial to my work flow. If someone told my CTO that terminals are an attack vector they might do something silly and ban them — might sound crazy but management has gone crazier things.

[aumerle]

So if I am to understand your proposal more concretely it is something like implement an escape code that the shell can use to turn off all other escape codes (presumably with some kind of listing mechanism) and then have the shell do that before launching any third party script/program/function? How would the shell know which escape codes the program it is running needs?

I can, kind of, see the utility of a pledge() type system within a single program, but in a shell, whose whole job is basically running programs it knows nothing about beyond their name? How would that work?

[mitchellh]

Sorry to be a broken record but I have no “proposal” whatsoever. It’s more of an information sharing and seeking discussion. I don’t know what I want yet except that I think we can do better. The end result could be that it’s all a terrible idea and that’s okay, but hopefully something comes out of it eventually.

Id love to continue this discussion, but I think HN threads probably aren’t the right medium. If you’d like I can email you or we can schedule a call. I’m not trying to seek privacy, I’d be happy for any to be recorded or shared publicly, I just don’t find HN to be a good place if you really want to dive into this!

[aumerle]

Of course, I didn't mean to put you in a spot. We can always continue this later once your thoughts have matured. Sadly I have an extremely full schedule so I dont think I have the badwidth to noodle on this at this stage but if and when you have something more concrete please do post it somewhere public and I will try to contribute to the discussion.

[moderation]

But strangely have a lot of time to post here

[sevg]

And a lot of time to post only about kitty XD

[remram]

aumerle is Kovid Goyal, the author of kitty.

[mitchellh]

Appreciate it! <3

[rockorager]

I've discussed with Mitchell a bit in the past on this, but there are a few ways to opt in to this. First, let's imagine there is some escape sequence that tells the terminal to ignore some set of escape sequences.

1. The shell could have a keybind (say, ctrl+enter) which runs the command with (for example) only styling enabled (CSI m sequences).

2. You could write a wrapper around any program to do the same. The shell doesn't need to know anything about the system, but instead you have a wrapper that disables and then reenables said sequences.

3. A program itself can opt in by turning on the feature at launch. This allows CLI / TUI developers to "safeguard" their programs from malicious attacks.