I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.

We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).

If I were to design terminal control today, I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. And I would definitely have a way to query the capabilities of the terminal directly, instead of looking it up in a terminfo database.

How do you keep that synchronized with the text for things like moving the cursor between words?

The one downside that has is if you separate the formatting from the data you can not recreate the session without keeping time info somehow. So, might need a fix for that.

The only other real alternative I'm aware of is moving the formatting into the API "stream" that communicates using the machine ABI. This is a terrible solution. It's what Windows uses.

You can program this message in the setup screen of the terminal. Maybe you can set up all the terminals in the computer center at night...

You can send Ctrl-E to a user with "write" or "wall"..

This answerback message is actually really old, exists even in mechanical ASR-33 teletypes:

https://en.wikipedia.org/wiki/Enquiry_character

It can also be triggered by the mysterious "here is" key on the ADM-3A.

https://dave.cheney.net/2017/08/21/the-here-is-key

One would hope that we're past the bad times, but at the same time brand new projects like the kitty terminal emulator let stdout read and delete arbitrary files. And verifying something is safe is just hard, these are not even e.g. memory safety bugs, they're "features".

Oh come on, you know what everyone means. "Output with potentially hostile content".

Right now it seems kitty will happily delete e.g. /tmp/.X11-unix/X0. That sounds fun.

https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-trans...

https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea319...

> And no unlike your claim, it does not read them.

    strace -e open,openat kitty
    printf '\e_Gf=24,s=10,v=20,t=f;%s\e\\' "$(echo -n /etc/passwd|base64)"
    openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 14

Me asking my editor to open /etc/passwd is me asking my editor to do something. My terminal emulator opening files and parsing them and deleting them just because I viewed untrusted content is something different. If you want to make that argument, you need to come up with an example where my editor accesses attacker-controlled files because I opened a random README.md.

Also, please read https://news.ycombinator.com/newsguidelines.html, and shove your attitude.

You very conveniently left out the fact that pretty much anything that views untrusted content has to parse files. If parsing files is where your "security boundaries" lie, I suggest you drop your computer off at the garbage dump. Hell if your editor has a preview function it too will parse untrusted content. Basically, to do anything software has to parse untrusted content. And just by the way, /etc/passwd is not attacker controlled. If the attacker has access to your filesystem already, she really doesnt need to use kitty to do anything. And "opening" README.md will not cause kitty to parse files, unless by "opening" you mean catting without -v. In which case we are back to your mommy told you to know better but you didn't listen.

At this point its obvious you are deliberately trying to spread FUD. I am done interacting with you. Good bye.

The general trick with parsing is to put it in a sandbox that cannot touch files, can only do limited syscalls, etc. This is what e.g. Chrome does.

But yes, it's obvious the Kitty author has no interest in making it more secure ( https://github.com/kovidgoyal/kitty/issues/2084) and it's obviously you take discussions about improving software security as attacks on your person.

Have a good day, sir.

Furthermore the next release of kitty has capability based security for remote control with public key crypto to keep the data safe: https://github.com/kovidgoyal/kitty/discussions/5320

I suggest you find a better place to move the goalposts in your attempts to smear and spread FUD.