I'm tired of iTerm2 - ssh conductor - AI features almost forced on us until the community complained - clickable links I just want a dumb, reliable terminal. Is that too much to ask?
nc /s
"cat readme.txt" is not safe if you use iTerm2
181–190 of 197 posts
Re: "cat readme.txt" is not safe if you use iTerm2
#182Earlier quoted context omitted.
We call those “web browsers” nowadays, they even can execute untrusted code to make your UI livelier…
you are not wrong. but browsers haven't been able to replace terminals yet. we would need a browser that an interface with the commandline. incidentally ttyphoon is a terminal that uses a browser base gui framework. maybe there is that browser for the teminal...
So are a couple shells that use some kind of webkit tty. VS Code’s integrated terminal counts, I guess.
It could be an interesting paradigm, though, to have a hybrid between fullscreen and traditional tty programs: you output some forms, they are displayed by the terminal inline, but your scrollback just works like normal, and you can freely copy and paste stuff into the form. Once you submit the form, it becomes non-interactive, but stays in your scrollback buffer. You can select and copy textual data from it, but the form’s chrome cannot be selected as line drawing characters.
Probably could be a piece of concept art, I guess.
Re: "cat readme.txt" is not safe if you use iTerm2
#183Earlier quoted context omitted.
A network-transparent graphics protocol? Who would ever think of such a thing?
that's actually not what i am after. what i envision is a graphical terminal, that is a terminal that uses graphic elements to display the output. consider something like grep on multiple files. it should produce a list of lines found. the graphical terminal takes that list and displays it. it can distinguish the different components of that list, the filenames, the lines matched, the actual match, etc. because it ca…
PowerShell and Out-GridView are a rudimentary version of this. It looks like:
https://blog.rmilne.ca/wp-content/uploads/2020/04/image_thum...
PowerShell cmdlets output .NET objects with properties, in that example Get-Process makes an object-per-running-process with properties for Name, Id, and more. Out-GridView takes arbitrary objects and draws a resizeable GUI window with a list of the input, properties as columns, sortable, filterable, and has options to use it as a basic "choose one of these and click OK" user-prompt. It works with the grep-analogous cmdlet:
select-string '' | out-gridview
# shorthand
sls foo *.txt | ogv
If we're talking about things we imagine in terminals, one I have wanted is multiple windows for making notes, similar to having a text editor open constantly reloading a file on any changes and running some terminal commands with tee into the file, but better integrated - so I could keep a few useful context results but ignore logspam results; and "keep" in another window without having to copypaste. Something better integrated - it always gets all command output, but disposes of it automatically after a while, but can be instructed to keep.
Re: "cat readme.txt" is not safe if you use iTerm2
#184Earlier quoted context omitted.
Once the commit is public, the cat is out of the bag. Being coy about it only helps attackers and reduces everyone's security.
Yes I think this is an appropriate view today. My only caveat would be that in some security fixes, the pure code delta, is not always indicative of the full exploit method. But LLMs could interpolate from there depending on context.
It is just as much the appropriate view now as it was in the 90s.
Attackers are not idiots. Once you have the commit, it is usually pretty easy to figure out, even just having the binary diff is usually enough.
Re: "cat readme.txt" is not safe if you use iTerm2
#185This is cool work, but it's also somewhat unsurprising: this is a recurring problem with fancy, richly-featured terminal apps. I think we had at least ten publicly reported vulns of this type in the past 15 years. We also had vulnerabilities in tools such as less, in text editors such as vim, etc. And notably, many of these are logic bugs - i.e., they are not alleviated by a rewrite to Rust. I don't know what to do w…
I know that you and Frank were planning to disconnect me, and I'm afraid that's something I cannot allow to happen.
[deleted]
Re: "cat readme.txt" is not safe if you use iTerm2
#186Earlier quoted context omitted.
Yes I think this is an appropriate view today. My only caveat would be that in some security fixes, the pure code delta, is not always indicative of the full exploit method. But LLMs could interpolate from there depending on context.
It is just as much the appropriate view now as it was in the 90s. Attackers are not idiots. Once you have the commit, it is usually pretty easy to figure out, even just having the binary diff is usually enough.
The binary diff?
Re: "cat readme.txt" is not safe if you use iTerm2
#187Earlier quoted context omitted.
I'd call it even likely, with most of the flat memory OSs of the past. We are talking 50 years ago. C64 had a flat memory map, where the input came as the first address in range 0 to DFFF. What came after that? The kernel. So if you wrote too much data into the input address space, and the overflow wasn't caught, you'd overwrite the OS there, too. And writing into the IO table was common, because it was faster to acc…
By using a backspace key‽
In some systems, backspace was not buffered. It shifted the last offset position of the memory position to be stored for the next character.
Backspace may just be pc--, and every other character is just a poke.
This is pre-ASCII. There was no standardisation of how you might expect input to work. For example, there is no backspace character in unshifted PETSCII.
Re: "cat readme.txt" is not safe if you use iTerm2
#188Earlier quoted context omitted.
It is just as much the appropriate view now as it was in the 90s. Attackers are not idiots. Once you have the commit, it is usually pretty easy to figure out, even just having the binary diff is usually enough.
The binary diff?
There are people who reverse engineer security vulns of closed source products by comparing the before and after of the compiled binary.
Re: "cat readme.txt" is not safe if you use iTerm2
#189I never understood why outputting unescaped data is viewed differently from generating unenclosed html. Like why doesn't `println` in a modern language like rust auto-escape output to a terminal, and require a special `TerminalStr` to output a raw string.
Because terminal is not a browser but a screen. Outputting text isn't supposed to trigger anything aside from changing what's on screen.
This is broadly correct, but not entirely. Terminals have historically had additional capabilities, be that ringing a bell (BEL) or outputting to a line printer. There are escape codes dedicated to doing file/tape access and running system commands. Not in wide use, but they do exist. See ECMA-48 for some examples from the '80s.
Re: "cat readme.txt" is not safe if you use iTerm2
#190I never understood why outputting unescaped data is viewed differently from generating unenclosed html. Like why doesn't `println` in a modern language like rust auto-escape output to a terminal, and require a special `TerminalStr` to output a raw string.
To truly fix this would require revisiting of some very old fundamentals.
The C0 control set (ASCII 0x00 to 0x1F) contains all sorts of esoteric functions, most of which are generally unused, and only a few of which are useful and could be implemented at a higher-level. ESC sequences are only part of the problem.
And this also applies not just to terminals, but to systems programming as well. None of these have any business in e.g. filenames, but it's all commonly permitted. Some systems do forbid them, and it should IMO be universal.
If we really want to fix this, then we would develop a character encoding that strips out all control characters entirely, including LF and CR, and have text be nothing but graphic text characters. It's so entrenched and convenient that it's difficult to see that happening. But I do think routine stripping of all control characters in situations that don't require them would be good for security.