←back to thread

414 points st_goliath | 2 comments | | HN request time: 0.507s | source
Show context
nmz ◴[] No.43974550[source]
If you're worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You'll be playing an endless game of whack-a-mole.
replies(2): >>43974686 #>>43984824 #
themk ◴[] No.43984824[source]
I do use abduco and dvtm, however, there is one major flaw in splitting the persistence and the emulator/multiplexer: if you detach, then reattach with a different terminal, with different capabilities, the emulator (which is running in abduco, say) doesn't know that it has to render differently.

Compared to tmux, which knows this, and can adjust the rendering to suite the new terminal.

replies(1): >>43985082 #
1. nmz ◴[] No.43985082[source]
Isn't this a bug of the software and not of the technology?

refetching terminfo capabilities seems an easy fix, you also get sigwinched which I imagine happens on a new terminal.

Mind you, I don't use abduco but do use dtach sometimes, I've accepted that I need screen and tmux with all its warts, like instead of using a scripting language like TCL/Lua for configuration it built its own frankenstein language that is severely limited.

replies(1): >>43991198 #
2. themk ◴[] No.43991198[source]
Most terminal emulators have no way of reporting their capabilities at run time. And having dtach or abduco modify the TERM environment variable of the already spawned child is not possible, and even if it did, there is no standard way to get the child to reread it.

So, no, the tech is kinda broken. The only correct thing to do is to have the attaching program also do terminal emulation (or, assume that you always attach with a compatible terminal).

You could make it a simpler form of emulation, and then have the more complex muxing ability as a separate program, at the cost of having to go through multiple emulation layers.