3 ms·

That seems even harder to do because an agent wouldnt be output text verbatim, which means you cant make use of a rendering bug (eg parsing escape codes). So y

by hnlmorg 2mo ago

That seems even harder to do because an agent wouldnt be output text verbatim, which means you cant make use of a rendering bug (eg parsing escape codes). So you’re back to depending on the agent to execute code locally. at which point you’ve already compromised the system so don’t need a tmux bug. I’ve spent a lot of time in tmux. Including writing a frontend for it. So I’m probably more familiar than most. And I hear a lot of people say tmux (specifically) is a vulnerability because it’s written in C. But I struggle to see how it’s any more of a vulnerability than (for example) coreutils. Or any other piece of software for that matter.

justonenote 1mo ago
appreciate the input from someone who works in the codebase, but ok maybe tmux is openbsd secure, but it still has quirks and combined with agent harnesses not understanding them its a large attack surface Imo, what may be in inconsequential rendering artefact in tmux or inconsequential behavior on user input like scroll back or pane focus or whatever convinced with bad parsing from "acme client" program cant result in RCE, Id be more surprised if this _wasnt_ the case and tmux+acme clents have no bugs that can be chained, no matter how battle tested tmux itself is.