Imperfect, incomplete, yet useful measures I take including building with some of Clang's sanitizers and running the program through a bubblewrap wrapper for filesystem sandboxing paired with a seccomp filter that allows a limited list of safer syscalls (including some W^X enforcement).
With the caveat this may be useful to guard against exploitation of bugs, not against a malicious terminal (which can e.g. quietly wait for a user to ssh or su and intercept the password, and then execute code on the background).
Not to dissuade people from hardening them as I'm all for that.
(I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
In which case the terminal can use the tmux session to carry out its evil deeds.
Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to.
Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering.
EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this:
X server ----[keyboard events]----------> terminal ------[pty w/keyboard events]----> [app/shell/tmux session]
<---[rendering instructions]----/ <----[pty w/output]------------------/
The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side.
You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that.
It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...
I suppose a bad actor could log keystrokes or terminal output and phone home. I can't think of anything more ring 0 than one's terminal. If you're especially evil you could register a domain that looks like an apt repo url and drop your payload during updates, so anybody inspecting traffic would probably miss it.
Very few admins would switch from bash (possibly zsh), and bash has tons of eyes looking over its codebase. Terminals are interchangeable and could direct the shell in ways that can be invisible to the user.
Wait until it has a following, and everyone knows who the developers are. Then if something is malicious, you atleast know who to blame. It's really the same as anything else.
It seems like an exploitable strategy, as long as people only know the developers online. The main problem with terminals compared to other infrastructure is that they often control pretty much everything and people become superusers in them.
Personally, I'd want something that keeps working even if I don't reboot immediately after a system update, especially for something as key as a terminal emulator.
That'd be the fault of Nvidia proprietary drivers (which are regularly known to cause lot of annoying problems+issues like that across the board) as systems without a hardware GPU can still normally create OpenGL contexts.
The day that driver mess is cleaned up a shit ton of problems will disappear overnight.
There seems to be some focus on tiling window managers, but it is not obvious to me (as a user of sway) what benefit this offers over any other terminal emulator.
Perhaps the focus on tiling wms is a justification for not having tabbing/splitting support built in.
Also, given xorg-dev dependency I assume that if one is on wayland, they are better off using alacritty.
If you would like a very silly reason, sometimes I want to copy logs to other devs really quickly from a server, but exporting them to a file and then rsyncing it back is just a bunch of commands and files I don't want to deal with. Because I have alacritty I'll do a cheeky hack and scale the font down to like 2pt, highlight everything and then copy it.
I can copy around 500 lines of logs this way. Quick and dirty.
Other than that IDK.
And about the tabbing and splitting. I got tired of all the terminal emulators I like not supporting it, and some contexts not supporting paging, and not having a nice way to review a long running process, and took the dive to learn tmux.
Tmux. A terrible solution to a bunch of stupid problems. Highly recommend.
Thanks for that. Disabling copy-on-select is really in my mind, priority #1 along with not having multiple clipboards I have to pass things between. It's insane that it's still broken. It's Xorg's equivalent to Firefox's crazy 20 year long ctrl-q drama.
What could they do instead? There's so many trivial solutions. A clipboard named pipe for instance, or at least something that operates like one. Read is paste, write is copy. That's a very 1970 style fix that could have been done 35 years ago. Then anything that can read and write from a file can interface the clipboard, opening up a whole new array of applications without setting aside "highlighting text" as having some special magical power.
Also having multiple clipboards is trivial, just have more of these special files. You can even set one aside if say some crazy old Xt application someone is still running only works with copy-on-select for some reason
A clipboard history is super trivial as well, just set up a pipe...
There's so many more unixy ways this could have been done. It's so dumb how it works. Heck dbus would be a less insane fix
> Disabling copy-on-select is really in my mind, priority #1
reading yoru entirely comment, I am not entirely sure if you mean changing how it's implemented or if you really would like to get rid of the user interface it has.
Because copy-on-select along with middle-click-to-paste is like ... the best thing. Tiny bits of data stuck that follow your cursor is the most information-at-my-fingertip feeling that I can get out of these machines.
I've hated this feature for 25 years. I run up against the design flaws of this limitation alone usually multiple times a day. From websites that try to have some funky JavaScript convenience (including nearly impossible to use things like medium) to applications that want to select the entire thing and destroy the clipboard as I'm trying to put something in. UX limitations and bad design make it utterly useless constantly.
The whole paradigm is broken. From applications that just select the entire document when you're one pixel off the line of selection, as if anyone has ever asked for that, to application interoperability with anything more than text, parity with windows OLE from around 1993, being still a total pipe dream. Drag and drop is still totally dependent on what toolkit the two programs you're using was written in.
That's nonsense! It'd be like a world where I can't pipe say output from python as input to a bash script because they were implemented in different languages and people would be like "welp. That sounds right. I don't see a problem here"
Also the world of programmers have decided they can go around randomly selecting shit to try to make my life dealing with clipboards easier even though it just makes it utterly unusable. I'm not going to go on a crusade to personally win that fight on a program by program basis. It'd be so much better to have flexibility on how clipboards work
Things could be amazing but instead we defend it being terrible.
Here's an example. Imagine where I can not only do basic asks like drag from inkscape to figma but also have something I'll call a "transport station" where I can drag things into a dock to share them with colleagues who can receive them and then put it into their application of choice, in a non-destructive, non-disruptive way that maintains the flow of productivity. Sound like a smooth and fantastic collaboration tool? I agree.
I've tried to make this, there's lots of fundamental problems that ought not exist. That's the power an unbroken clipboard could have.
What do you do with computers where you don't viscerally feel these limitations daily?
I do feel these limitations daily. Sometimes I feel I have this knack where when I start using something it immediately breaks whenever I want to do something that is a little bit outside the happy path. It's frustrating.
I will grant you that the situation concerning copy/paste as a whole is "not great", I have certainly run into issues before. But this interaction where selecting a word either by dragging a mouse along some text, double or triple clicking to select and then being able to paste this text somewhere else just by pressing the middle-mouse button is just really god computing.
Crucially: This is a very local interaction that does not interact with my clipboard at all. Which lets me copy two things at the same time. I use this all the time for copying/pasting username/password combos.
But that reminds me - the correct way to do this is setting up my password manager to do it for me...
I am interested in the "transport station" you described. I am currently trying to find a way to seamlessley working on multiple computers at the same time, and a shared clipboard like that would be really iteresting. Also to synchronize to my phones' clipboard. Do you have some already written notes on the issues that you ran into ?
I just search for the beginning of what I want to copy, select the beginning with the mouse, scroll to the bottom, and shift-click to select all of it.
No problem copying a few MBs of output this way (100,000 lines for instance).
I'm guilty of gzip + base64'ing short files, and copying and pasting them rather than scp/rsync. When the whole toolbox is there, sometimes it's fun to see what kind of Rube Goldberg machine you can make :)
To copy the entire scrollback buffer from Alacritty: <C-S-Space>gVGy<C-S-Space>. Ctrl+Shift+Space: enter Vi mode; g: move the cursor to the top of the scrollback buffer (like gg in Vi/Vim); V: start linewise selection; G: move the cursor to the bottom of the scrollback buffer; y: copy to clipboard and clear selection (like "+y in Vim); Ctrl+Shift+Space: exit Vi mode.
Learn what’s possible in Vi mode from the key_bindings section of the alacritty.yml config, largely the ones with `mode: Vi` and similar. You’ve got the usual things like hjkl navigation, Ctrl+B and Ctrl+F to go Backwards and Forwards a page, / to search, all that sort of stuff. (Though I will note that ? to search backwards doesn’t work, because Alacritty is using winit’s currently utterly insufficient keyboard API for its bindings, see <https://github.com/alacritty/alacritty/issues/5251>.) Also in alacritty.yml, scrolling.history defines how many lines are kept in the buffer (defaults to 10,000).
It's about having everything available either in front of you (tiled in the current workspace) or in a single keystroke (to move to the desired workspace). I like it a lot, especially in comparison to what I see my coworkers doing: move their windows around in order to uncover other windows or alt tab constantly until you either find your desired window or you pass it accidentally.
You’re talking about the benefits of tiling window managers compared to floating window managers. The question was instead “You say Darktile is ‘designed for tiling window managers’; what does that actually mean? How is it different from other terminal emulators?”
When I hear that a terminal is "designed for tiling window managers", I expect that it:
- Doesn't do any kind of tabs, or split view, or switching between different "buffers", under the assumption that you use your window manager for that stuff
- Always fills the entire window with the contents of the terminal, regardless of what size the window is (e.g. non-integer multiple of size of a character cell), and doesn't draw its own window decorations
- Launches very quickly
- Generally has a flat, minimalist aesthetic. Uses (ideally configurable) keyboard shortcuts instead of a toolbar, menu bar, or right-click menu, and is configurable by editing a file.
Some terminals are like this already, and I don't know how well Darktile lives up to it. But it's a very different design direction from, say, GNOME Terminal.
I'd love to know about Wayland support as well. I'm pretty stuck on Alacritty right now, but I'll always check out something else compatible that has sixels and ligature support.
I believe it supports sixels and ligatures (but I haven't tried those, I don't care much about them).
It works on Wayland - I'm running it under Sway and I'm very happy with it. It also supports server/daemon mode where server does all the rendering and shares glyph cache between windows - lower memory usage & faster startup.
It does indeed support Sixels, and is super fast too. Also, the official build only runs on Wayland afaik (my friend tried to build it from source in xorg but during compilation it would check for a wayland environment and then fail). Pretty sure there was an xorg port floating around somewhere though.
On Linux, I found it to be super slow. TUI apps like neovim were sluggish in certain contexts. I couldn't figure out how to increase text throughput either. The developer seems more focussed on maintaining MacOS performance (I'm not complaining, just warning any linux users).
Consider yourself lucky. It’s a terrible standard, really. It wasn’t very consistent even with DEC terminals alone. Plus it’s a LOT of bytes per image.
From today's persepective, maybe. However, it is entirely consistent with the terminal control sequences of that era which can't use CL for transmitting data. It's limited to control, or else you wouldn't be able to cancel operations at arbitrary points. Sixel data is using GL, CR and GR [the high six bits], and from the point of view of fitting in with the design constraints, it's actually quite elegant.
It’s more or less the same protocol used to print graphics on DEC printers, but now true colour is grafted on top of it. I bet soon we’ll be able to show HDR10 movies. ;-)
For speed, it's marginal at best. Very few non-GPU terminals are anywhere near peak performance anyway, because once you get past a certain point the only noticeable difference tends to be what happens when you accidentally dump a huge chunk of text to the terminal.
But it does allow fun stuff like shaders. E.g. I added some outlines in the shaders for my version of Kitty (not public anywhere - my hacky shaders are a mess) to let me use more transparent windows without making things unreadable.
It should help on low-power devices, and with power consumption. In theory at least. Moreover, it's a must if you want image support (I saw this terminal emulator supported sixels, opened an issue about the kitty protocol).
I don't see why it'd make a positive impact on power consumption or low power devices. Most of the time terminals consume very little processing power. You get brief bursts while scrolling lots of text, but that tends to be a tiny proportion of usage.
Image support and sixel support exists on any number of terminals with no GPU support. A majority of the ones I've used w/sixel support in fact are totally oblivious to GPUs.
Keep in mind sixel originated on terminals a few orders of magnitude slower than even modern mobile devices. For most uses you'll not even benefit from more than a basic 1980's era blitter in terms of acceleration, but given the data volumes even that will not make much difference with a well written terminal app (which will minimize copying to start with)
Yeah, unless you want shaders, that's pretty much it. The irony is that most of the GPU based terminals takes little to no advantage of doing anything fancy with shaders which would be the main other thing they can offer.
But even there CPU based rendering can be fast enough for most things. E.g. I hacked xst to add outlines by just crudely rendering things three times, and that was more than fast enough still on CPU only.
The current glow I add with shaders on Kitty would be hard to do fast enough, but a close approximation with cached glyphs would not be hard.
All I want from a terminal is built in support for double width and double height. Sixel and Tektronix would be nice too. Extra points if it can do line drawing, PETSCII and Teletext mosaics without font support. Oh… and overlines, so tmux can have a proper status bar.
Xterm does all this :) By the way what apps do you have that still use double width and height? I have a vt520 here and I'd love to try that but I don't think any currently popular terminal UI Apps support that
Most don't even read termcap or termdb anymore and just pump out xterm no matter what display is set to :(
I use it on my own CLI apps. It’s nice to see my colleagues gasp when I’m screencasting and an error message pops up in red 2x2 type. Most people don’t know Apple’s Terminal.App does a near-perfect VT emulation.
Double width and height are tricky - they are line-based and that makes using them tricky in full-screen apps. Tmux and other screen managers filter them out.
76 comments
[ 2.8 ms ] story [ 125 ms ] threadNot to dissuade people from hardening them as I'm all for that.
(I'm sure you're aware since you pointed out these measures are incomplete. Just spelling it out.)
A terminal needs to be able to spawn an unconstrained shell or other process linked to a pty that it controls the IO with.
That ability can equally be used for malicious purposes.
E.g. if the user can use the terminal to ssh anywhere, then the terminal itself can too.
There certainly can be situations were a constrained terminal could be useful too, though
Keep in mind that the terminal app is what reads keyboard events and passes them on to what it runs, and the terminal app reads the output back from the attached application (or tmux session) to render them to the screen. It has full control to monitor what you do, and to inject additional commands (and hide the responses) to whatever you connect it to.
Anything you can do in the terminal, the terminal can also do without your permission unless you do far more complicated filtering.
EDIT: I think what might not be clear here is how a terminal operates. It'll differ by operating system and winding system, but on Linux what you have is this:
The terminal is always a middleman, and can send whatever it wants to the app/shell/tmux session or whatever else you connect to it. It could "just" send your keypresses, or it can do macro expansions, or it could just randomly take over the endpoint on the other side.You could conceivably still lock this down, but it would involve writing something that either replicates the keyboard event pipeline of the terminal to verify that what is sent over the pty matches the inbound keyboard events, or applying heuristics to what is sent to block things that seems odd, so it's potentially possible to do "something" useful here. E.g. something that blocks and pops up a warning if the pty "keyboard events" suddently contains the string "curl" when that string hasn't been seen in the keyboard events from the X server for example could be useful, but bubblewrap certainly can't do anything like that.
It'd be quite interesting to write a tool that wraps an app and allows you to script monitoring and/or munging of what goes over its sockets, though...
If it is malicious, you're screwed. If it has bugs you might be screwed just viewing a malicious text file.
Just tried to run alacritty:
https://megous.com/dl/tmp/4af49886c7c9854d.png
Personally, I'd want something that keeps working even if I don't reboot immediately after a system update, especially for something as key as a terminal emulator.
The day that driver mess is cleaned up a shit ton of problems will disappear overnight.
Not an option to buy anything else for a sane price at the moment sadly, due to crypto craze. ;)
https://wiki.archlinux.org/title/Alacritty#Requires_hardware...
https://megous.com/dl/tmp/4a76e64deddee2f5.png
Perhaps the focus on tiling wms is a justification for not having tabbing/splitting support built in.
Also, given xorg-dev dependency I assume that if one is on wayland, they are better off using alacritty.
I can copy around 500 lines of logs this way. Quick and dirty.
Other than that IDK.
And about the tabbing and splitting. I got tired of all the terminal emulators I like not supporting it, and some contexts not supporting paging, and not having a nice way to review a long running process, and took the dive to learn tmux.
Tmux. A terrible solution to a bunch of stupid problems. Highly recommend.
I'm clearly not smart enough to do it without having to think about the process every time
What could they do instead? There's so many trivial solutions. A clipboard named pipe for instance, or at least something that operates like one. Read is paste, write is copy. That's a very 1970 style fix that could have been done 35 years ago. Then anything that can read and write from a file can interface the clipboard, opening up a whole new array of applications without setting aside "highlighting text" as having some special magical power.
Also having multiple clipboards is trivial, just have more of these special files. You can even set one aside if say some crazy old Xt application someone is still running only works with copy-on-select for some reason
A clipboard history is super trivial as well, just set up a pipe...
There's so many more unixy ways this could have been done. It's so dumb how it works. Heck dbus would be a less insane fix
reading yoru entirely comment, I am not entirely sure if you mean changing how it's implemented or if you really would like to get rid of the user interface it has.
Because copy-on-select along with middle-click-to-paste is like ... the best thing. Tiny bits of data stuck that follow your cursor is the most information-at-my-fingertip feeling that I can get out of these machines.
I've hated this feature for 25 years. I run up against the design flaws of this limitation alone usually multiple times a day. From websites that try to have some funky JavaScript convenience (including nearly impossible to use things like medium) to applications that want to select the entire thing and destroy the clipboard as I'm trying to put something in. UX limitations and bad design make it utterly useless constantly.
The whole paradigm is broken. From applications that just select the entire document when you're one pixel off the line of selection, as if anyone has ever asked for that, to application interoperability with anything more than text, parity with windows OLE from around 1993, being still a total pipe dream. Drag and drop is still totally dependent on what toolkit the two programs you're using was written in.
That's nonsense! It'd be like a world where I can't pipe say output from python as input to a bash script because they were implemented in different languages and people would be like "welp. That sounds right. I don't see a problem here"
Also the world of programmers have decided they can go around randomly selecting shit to try to make my life dealing with clipboards easier even though it just makes it utterly unusable. I'm not going to go on a crusade to personally win that fight on a program by program basis. It'd be so much better to have flexibility on how clipboards work
Things could be amazing but instead we defend it being terrible.
Here's an example. Imagine where I can not only do basic asks like drag from inkscape to figma but also have something I'll call a "transport station" where I can drag things into a dock to share them with colleagues who can receive them and then put it into their application of choice, in a non-destructive, non-disruptive way that maintains the flow of productivity. Sound like a smooth and fantastic collaboration tool? I agree.
I've tried to make this, there's lots of fundamental problems that ought not exist. That's the power an unbroken clipboard could have.
What do you do with computers where you don't viscerally feel these limitations daily?
I will grant you that the situation concerning copy/paste as a whole is "not great", I have certainly run into issues before. But this interaction where selecting a word either by dragging a mouse along some text, double or triple clicking to select and then being able to paste this text somewhere else just by pressing the middle-mouse button is just really god computing.
Crucially: This is a very local interaction that does not interact with my clipboard at all. Which lets me copy two things at the same time. I use this all the time for copying/pasting username/password combos.
But that reminds me - the correct way to do this is setting up my password manager to do it for me...
I am interested in the "transport station" you described. I am currently trying to find a way to seamlessley working on multiple computers at the same time, and a shared clipboard like that would be really iteresting. Also to synchronize to my phones' clipboard. Do you have some already written notes on the issues that you ran into ?
[1] https://github.com/bugaevc/wl-clipboard
No problem copying a few MBs of output this way (100,000 lines for instance).
Learn what’s possible in Vi mode from the key_bindings section of the alacritty.yml config, largely the ones with `mode: Vi` and similar. You’ve got the usual things like hjkl navigation, Ctrl+B and Ctrl+F to go Backwards and Forwards a page, / to search, all that sort of stuff. (Though I will note that ? to search backwards doesn’t work, because Alacritty is using winit’s currently utterly insufficient keyboard API for its bindings, see <https://github.com/alacritty/alacritty/issues/5251>.) Also in alacritty.yml, scrolling.history defines how many lines are kept in the buffer (defaults to 10,000).
- Doesn't do any kind of tabs, or split view, or switching between different "buffers", under the assumption that you use your window manager for that stuff
- Always fills the entire window with the contents of the terminal, regardless of what size the window is (e.g. non-integer multiple of size of a character cell), and doesn't draw its own window decorations
- Launches very quickly
- Generally has a flat, minimalist aesthetic. Uses (ideally configurable) keyboard shortcuts instead of a toolbar, menu bar, or right-click menu, and is configurable by editing a file.
Some terminals are like this already, and I don't know how well Darktile lives up to it. But it's a very different design direction from, say, GNOME Terminal.
Does this support Wayland? It's not clear, I can see someone has raised the question in an issue.
I've been using kitty for a while which supports GPU rendering and has Wayland support too.
I believe it supports sixels and ligatures (but I haven't tried those, I don't care much about them).
It works on Wayland - I'm running it under Sway and I'm very happy with it. It also supports server/daemon mode where server does all the rendering and shares glyph cache between windows - lower memory usage & faster startup.
How do they compare? Are there significant differences or are they just marginally different one from the other?
Kitty has fully featured window management built in, also kittens
Darktile seems to be simpler.
Probably good choice since, after all, terminal graphics is simple enough for the engine to be capable to render.
It's a bit disappointing to me who was expecting some kind of (likely to be excess) rocket science, but I know that's not a fair complaint :-)
[1] https://github.com/hajimehoshi/ebiten
https://github.com/slavfox/Cozette
But it does allow fun stuff like shaders. E.g. I added some outlines in the shaders for my version of Kitty (not public anywhere - my hacky shaders are a mess) to let me use more transparent windows without making things unreadable.
Image support and sixel support exists on any number of terminals with no GPU support. A majority of the ones I've used w/sixel support in fact are totally oblivious to GPUs.
Keep in mind sixel originated on terminals a few orders of magnitude slower than even modern mobile devices. For most uses you'll not even benefit from more than a basic 1980's era blitter in terms of acceleration, but given the data volumes even that will not make much difference with a well written terminal app (which will minimize copying to start with)
Still not worth it it me, I try to keep my gpu usage as low as possible to save on battery life, and this just sounds overkill.
But even there CPU based rendering can be fast enough for most things. E.g. I hacked xst to add outlines by just crudely rendering things three times, and that was more than fast enough still on CPU only.
The current glow I add with shaders on Kitty would be hard to do fast enough, but a close approximation with cached glyphs would not be hard.
Most don't even read termcap or termdb anymore and just pump out xterm no matter what display is set to :(
Double width and height are tricky - they are line-based and that makes using them tricky in full-screen apps. Tmux and other screen managers filter them out.