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.
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?
Yup kitty revolutionized my terminal experience, hence the passion. I am sorry but since you seem to be passionate enough about ghostty to try to shill it in a article about a security vulnerability in it, I don't think you have a leg to stand on when it comes to complaining about my posts.
If you want to claim that ghostty is developed very rapidly it behoves you to do a little research and compare it against its peers before making that claim.
You proposal does not address this issue since shells would still need full privileges.
This entire class of exploits (query responses with user controlled data leading to shells executing commands) would be removed if shells just moved to using the kitty keyboard protocol with all key events represented as escape codes and implemented a full escape code parser for data received form the terminal. You cannot embed an escape code inside another, or while technically you can, it is trivial to implement a security policy of disallowing these in both terminals and shells. Then barring implementation bugs in the escape code parser (which can easily be shipped as a standalone native code library) you dont have this entire class of issues and the associated one that the bracketed paste hack was created to address.
It's not even slightly tricky, just use self pipe. I have no idea why the maintainer of make rejected it. He says select has different signatures, but select is in POSIX, so unless he is porting to a non POSIX platform, it's irrelevant and even if he is, I doubt it is that hard to write a wrapper to abstract the non POSIX compatible implementation of select. Then he complains about needing to do CLOEXEC on the self pipe. This is trivial (one line) on Linux using pipe2 and about 5 lines of code on other platforms. Given that he says make does not use threads its also perfectly robust without pipe2.
Opting for a harder algorithm just to avoid a few lines of compatibility shims seems like very much the wrong tradeoff.
Ah yes, in that case there no terminals that implement it indeed. Though there are a few that implement changing window size via escape code, though in units of cells not pixels. Generally speaking I dont see how applications can use tcsetwinsize() robustly, given that the size in pixels of a cell is determined by font properties and applications runing in the terminal have no knowledge of these, therefore cannot set both the pixel and cell sizes at the same time.
Lots of modern terminals support ws_xpixel and ws_ypixel. Hell even the venerable xterm supports it. It is used primarily for displaying raster graphics in modern terminals, see for example: https://sw.kovidgoyal.net/kitty/graphics-protocol/#getting-t...