iTerm2 critical security release(iterm2.com)
iterm2.com
iTerm2 critical security release
https://iterm2.com/downloads/stable/iTerm2-3_5_11.changelog
454 comments
That's not unreasonable code in itself, it's writing to the file only if verbose mode is enabled.
This is the commit which disabled verbose mode, just before the code which removed verbose framer logging entirely: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
This is the commit which enabled VERBOSE mode: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e... (from Jul 3, 2024)
That is probably just from having set VERBOSE=1 while implementing or debugging something and forgetting to revert it to VERBOSE=0 before committing.
This is the commit which disabled verbose mode, just before the code which removed verbose framer logging entirely: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
This is the commit which enabled VERBOSE mode: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e... (from Jul 3, 2024)
That is probably just from having set VERBOSE=1 while implementing or debugging something and forgetting to revert it to VERBOSE=0 before committing.
This happened to me so often that I made a git pre-commit hook to catch it: https://github.com/nobssoftware/nocommit for the word NOCOMMIT
Includes a GitHub CI action to prevent merging it in to master
It has caught so many of these mistakes for me…
Includes a GitHub CI action to prevent merging it in to master
It has caught so many of these mistakes for me…
I only heard of pre-commit hooks like 20 times in the wild and I really want to emphasize how badly that number should be 10x larger. Got a team completely unaware they existed once.
I really do wish that git itself would like check for a `.githooks` directory and prompt if it should set `core.hooksPath` to that path (probably would need to notify on pull when any files in it changed for security reasons)
I would also love if it detected a `.gitmessage` for message the message template without needing to set it up for each repo, but that is a different matter.
I would also love if it detected a `.gitmessage` for message the message template without needing to set it up for each repo, but that is a different matter.
This is why all "temporary" settings go in .gitignored files or equivalent,
or on no-merge testing branches,
and we have test on the release branch that asserts for each config value that it is set to a safe value,
and we have a test that reflectively asserts that every config key has a value assertion test.
or on no-merge testing branches,
and we have test on the release branch that asserts for each config value that it is set to a safe value,
and we have a test that reflectively asserts that every config key has a value assertion test.
Or non-default compile time flags. That’s how I handle verbose debugging in my terminal emulator.
This variable might have been better named LOG_ALL_STDIO_TO_TMP. Would have made it more obvious during self-review that it shouldn't be shipped.
Or even better:
# TODO: set back to 0
This appears as a warning in my editor, and of course is greppable
# TODO: set back to 0
This appears as a warning in my editor, and of course is greppable
Don't mind me with 100s of // TODO in my codebases.
Then # HACK: or # FIXME: or # DO_NOT_SHIP... anything greppable and distinct enough to error in CI
or having a commit hook that fails if the code contains such string
In typescript dev I made “console.log” a linting error that cannot be merged. The occasional legitimate need uses console.info
I think print debugging is fine. It has a time and place. But ideally find a way to protect yourself from accidentally leaving it in. It’s such an easy mistake to make.
I think print debugging is fine. It has a time and place. But ideally find a way to protect yourself from accidentally leaving it in. It’s such an easy mistake to make.
Well this is an instance of writing to a file, so the JS equivalent would be calling .write on a file stream. Not exactly comparable, it wasn't literally a debug print() that someone had forgotten to delete but a log file that was enabled when verbose logging was enabled.
in similar situations, instead of saying "VERBOSE=1", I say "VERBOSE=getenv("MY_NAME_MY_APP_VERBOSE") == '1'", and set this env variable in my terminal when needed. This way there is zero chance I commit verbose-enabled debug code.
not a typescript dev here: what do you use instead of console.log for debugging?
It sounds like they use console.log, but they don't let it ship in their production code.
console.log is reserved for devtime debugging and is a linting error so it cannot be left in. console.info is used in the occasional time we actually want to write things to console (along with console.warn, console.error, console.group, console.table, etc.).
It's all it took. Just making a clear distinction between the two and communicating it with the team.
It's all it took. Just making a clear distinction between the two and communicating it with the team.
I liked tslog last time I tried it.
It’s been around for 3 years?
About six months. File was originally authored a few years back, but looks like this slipped in here: https://gitlab.com/gnachman/iterm2/-/commit/5db0f74bf647f6d5...
> A bug in the SSH integration feature caused input and output to be logged to a file on the remote host. This file, /tmp/framer.txt, may be readable by other users on the remote host.
Oof. This is nasty. Some folks may not have access to some machines that they've SSH'd into anymore where files like this may or may not exist.
Oof. This is nasty. Some folks may not have access to some machines that they've SSH'd into anymore where files like this may or may not exist.
This seems relevant:
When does this occur? --------------------- The issue occurs if both of the following conditions are true:
1. Either: a) You used the it2ssh command, or b) In Settings > Profiles > General, the Command popup menu was set to "SSH" (not "Login Shell", "Command", or "Custom Command") AND "SSH Integration" was checked in the SSH configuration dialog. That dialog is shown when you click the Configure button next to the ssh arguments field in Settings.
2. The remote host has Python 3.7 or later installed in its default search path.
When does this occur? --------------------- The issue occurs if both of the following conditions are true:
1. Either: a) You used the it2ssh command, or b) In Settings > Profiles > General, the Command popup menu was set to "SSH" (not "Login Shell", "Command", or "Custom Command") AND "SSH Integration" was checked in the SSH configuration dialog. That dialog is shown when you click the Configure button next to the ssh arguments field in Settings.
2. The remote host has Python 3.7 or later installed in its default search path.
Yeah #1 reduces the surface area for sure, #2 maybe not so much :)
#1 greatly reduces the surface area, and #2 doesn't _increase_ the surface attack limited by #1, in case people are reading this incorrectly.
I have Python 3.7 or later installed on my default search path, but after checking none of my servers have a `/tmp/framer.txt` file.
you need both #1 and #2 to be true.
Long live EL8
This bug almost never occurs as it's a very esoteric feature that 99% of people here never heard or used. If you're, however, the type of user who decides not to use `bash` or `zsh` and instead wants `ssh` as their default terminal command there are probably other unusual features that you use in other apps exposing you to many other attack surfaces that you also need to worry about beyond just iTerm.
I just want to sing some praises for iterm2. I've been using it for work and fun for many years now and will continue to use it and send a donation again as I did once before.
Agree. It's one of the best things I use all the time.
> I deeply regret this mistake and will take steps to ensure it never happens again.
I always get a little... sigh-y when I read statements like these. What steps? I'm not even sure what I would do to ensure something like that wouldn't happen again. Build some automated tooling to run the software that exercises every single feature it has, and capture system calls to ensure that it never opens or writes to files? That sounds like a very difficult thing to do (to the point that I wouldn't even try, especially for a GUI app), but anything less doesn't feel like you can ensure it won't happen again.
I always get a little... sigh-y when I read statements like these. What steps? I'm not even sure what I would do to ensure something like that wouldn't happen again. Build some automated tooling to run the software that exercises every single feature it has, and capture system calls to ensure that it never opens or writes to files? That sounds like a very difficult thing to do (to the point that I wouldn't even try, especially for a GUI app), but anything less doesn't feel like you can ensure it won't happen again.
Gazillions of dollars have been spent on fuzzing Chrome/Chromium, and they're still finding dozens of serious issues per year. Same with every other major product. The reality seems to be that we, as programmers, can't do any better than this. If that's the case, it's unfair to lay it all at the feet of this one guy.
Exactly. Anyone complaining should donate time or money.
I would even go so far as: if you see reactions like "this is shoddy work, the author should Just Do Better", you can generally surmise that the person making the comment has a poor understanding of fallibility and will make a lot of these mistakes themselves.
Given the brevity of the security report, I figure the author wanted to get the relevant details about the *incident* posted as fast as humanly possible. However, it does seem appropriate to acknowledge that just because they're being terse doesn't mean they don't understand how big of a mistake it was.
That being said, I would also strongly expect a more in-depth blog post following up, with details about just the sort of thing you're mentioning.
That being said, I would also strongly expect a more in-depth blog post following up, with details about just the sort of thing you're mentioning.
I understand the interest about this bug, but to my understanding this is an unpaid hobby project?
If that's true I don't feel entitled to expect anything here.
If that's true I don't feel entitled to expect anything here.
I think your parent comment used "expect" to mean "predict" rather than "demand"?
[deleted]
You can expect anything you want in software you use, and choose not do you software that fails to meet expectations.
A software author who takes pains to publish his work and who accepts financial donations, is likely interested in maintaining his reputation and improving his skill and quality.
Finally, security bugs are in a class of their own. Giving out free junk is OK. Giving out free secret poison is not.
A software author who takes pains to publish his work and who accepts financial donations, is likely interested in maintaining his reputation and improving his skill and quality.
Finally, security bugs are in a class of their own. Giving out free junk is OK. Giving out free secret poison is not.
> Finally, security bugs are in a class of their own. Giving out free junk is OK. Giving out free secret poison is not.
It is not if it was done maliciously. If the code you got for free contained some mistakes it's ultimately your responsibility - You didn't have to take that pill you got at the party.
Accepting donations could change this, but I would say it depends on how they are presented - "campaign donations" ala Joey Hess or "Hey thanks for the the party last night, here's $40 to cover some of the booze!"
Alternatively, I'm curious how you feel about companies offering you "free email, free search, free image hosting, free social media" etc, (actually, in exchange for all your behavioral data) ((actually, even if you never directly accept anything from us))?
It is not if it was done maliciously. If the code you got for free contained some mistakes it's ultimately your responsibility - You didn't have to take that pill you got at the party.
Accepting donations could change this, but I would say it depends on how they are presented - "campaign donations" ala Joey Hess or "Hey thanks for the the party last night, here's $40 to cover some of the booze!"
Alternatively, I'm curious how you feel about companies offering you "free email, free search, free image hosting, free social media" etc, (actually, in exchange for all your behavioral data) ((actually, even if you never directly accept anything from us))?
Right, you get it in toto IMHO: this is the least worst thing they can say, and also the best thing they can say.
If they don't apologize, that'd be worse.
If they don't indicate they'll take steps to prevent this from happening in the future, that'd be worse.
If they had all the steps ready right now, I'd be confused because they should have A) fixed the bug B) deployed the fix C) communicated the bug exists and a fix was deployed. Blending that with D) postmortem would show an undisciplined approach.
If they claimed the ability to prevent all bugs ever, or at least, all unintentional file writes, I'd be confused because it's impossible to prove it never writes to a file.
A good start is to do what he did (delete the ssh logging altogether), and start investigating automated ways to validate if/when files are accessed. The cool thing about macOS dev is there's a ton of tooling that leaps and bounds beyond cross-ecosystem tooling. I wouldn't be very surprised if someone linked an obscure mid-1990s technical note that lets you set an NSArray of paths that are allowed access, or if Instruments had some built-in dtrace integration that could pull this off. Couple running that in CI, make sure you got test coverage, and you've done the best you can.
(n.b. a lot of it seems to hinge on "I deeply regret this mistake and will take steps to ensure it never happens again." being read as "I deeply regret this mistake. I will do things until I can, absolutely, 100%, foreever, guarantee it'll never ever happen again." For the young and impressionable: the blog post is great, there's ~0 you could do better here)
If they don't apologize, that'd be worse.
If they don't indicate they'll take steps to prevent this from happening in the future, that'd be worse.
If they had all the steps ready right now, I'd be confused because they should have A) fixed the bug B) deployed the fix C) communicated the bug exists and a fix was deployed. Blending that with D) postmortem would show an undisciplined approach.
If they claimed the ability to prevent all bugs ever, or at least, all unintentional file writes, I'd be confused because it's impossible to prove it never writes to a file.
A good start is to do what he did (delete the ssh logging altogether), and start investigating automated ways to validate if/when files are accessed. The cool thing about macOS dev is there's a ton of tooling that leaps and bounds beyond cross-ecosystem tooling. I wouldn't be very surprised if someone linked an obscure mid-1990s technical note that lets you set an NSArray of paths that are allowed access, or if Instruments had some built-in dtrace integration that could pull this off. Couple running that in CI, make sure you got test coverage, and you've done the best you can.
(n.b. a lot of it seems to hinge on "I deeply regret this mistake and will take steps to ensure it never happens again." being read as "I deeply regret this mistake. I will do things until I can, absolutely, 100%, foreever, guarantee it'll never ever happen again." For the young and impressionable: the blog post is great, there's ~0 you could do better here)
Better would say "After the immediate problem is patched, I will post more details about future plans for security, probably within X days. I welcome suggestions on the feature tracker."
Empty vague promises aren't really better than being quiet. They rely entirely on the reader's good faith, but if that good faith exists (which it likely does for this excellent product and excellent developer), then the promise adds no information.
Empty vague promises aren't really better than being quiet. They rely entirely on the reader's good faith, but if that good faith exists (which it likely does for this excellent product and excellent developer), then the promise adds no information.
such a bad take. as a software engineer thing like this happen all the time. no matter scale we will screw it.
what steps we can take is that it's now a lesson to make it more caution when we went into that path.
what steps we can take is that it's now a lesson to make it more caution when we went into that path.
Another comment mentioned using a linter to prevent 'console.log' from being mergeable in a PR, and this is exactly the kind of approach I'd take. Preventing an invalid state from existing is a pretty useful principle.
Coming from medical device background: procedures. Documents that explicitly lay out the things you have checked, how you checked it, date of check, and your signature on it at the end.
When you learn or anticipate a new failure mode, thats a new step in the corresponding procedure. Sometimes you'll be able to automate this stuff, but when the impact is this deep, it will not kill you to add some manual workload to your release process.
When you learn or anticipate a new failure mode, thats a new step in the corresponding procedure. Sometimes you'll be able to automate this stuff, but when the impact is this deep, it will not kill you to add some manual workload to your release process.
> The code to write to log files in SSH integration
has been deleted
Seems like a good first step.
Seems like a good first step.
Talk is cheap, send patches
there's lots of things you can do with deploy scripts to help prevent bozo errors from devs. Just like the code looking for credentials uploaded to github, you can do whatever type of searches that you as a developer is prone to making. it's a cya type of thing.
Just a reminder that iTerm is FOSS: https://github.com/gnachman/iTerm2
whats the paid alternative?
Panic’s Prompt, I guess? I bought it because it’s now bundled with the iOS app, which I already used.
It’s fine. Not mindblowing, not bad at all. Just fine.
It’s fine. Not mindblowing, not bad at all. Just fine.
I know it's largely personal preference but are there any strongly compelling reasons to use iTerm2 over stock Terminal on macOS in 2025? Despite recommendations, I've been wary of security and privacy issues much like this SSH bug.
The killer feature for me is Edit>Selection Respects Soft Boundaries, which lets you copy text from inside windows defined INSIDE the terminal - like tmux or emacs splits - where iTerm figures out that, e.g., a pipe character is a window boundary.
Two more:
2) if you accidentally close a tab/window, you have a few seconds to hit ⌘z and the window will reappear as if you never closed it!
3) Minimum color contrast. If your terminal color scheme and what you're running's color scheme interact poorly to create something that would be unreadable, iterm notices and you can have it override those colors to be something of higher contrast, automatically.
But that's just my killer features. iTerm is like Word - it is a bloated monster with thousands of features. Nobody needs them all, but nobody agrees on which ones they need.
Two more:
2) if you accidentally close a tab/window, you have a few seconds to hit ⌘z and the window will reappear as if you never closed it!
3) Minimum color contrast. If your terminal color scheme and what you're running's color scheme interact poorly to create something that would be unreadable, iterm notices and you can have it override those colors to be something of higher contrast, automatically.
But that's just my killer features. iTerm is like Word - it is a bloated monster with thousands of features. Nobody needs them all, but nobody agrees on which ones they need.
Being able to SSH into multiple machines, and mirror your keyboard across all of them is my favorite feature.
... a feature I've never used or had a need for thus showing my point precisely :)
Honestly, it sounds like an anti-feature or a crutch.
Designed to help environments that haven't reached 2010 era of automation of Salt or Chef.
Designed to help environments that haven't reached 2010 era of automation of Salt or Chef.
Meh, I've used it numerous times in situations like setting up some clustered software to explore for the first time. Just fire up your 3 vms, ssh into each of them in their own panes, hotkey to activate broadcast mode, start creating/editing your config(s) and tuning your server.
It really is useful in the right scenarios, sure you shouldn't adopt it as your "official method for provisioning production servers" but that doesn't mean it doesn't have a legitimate use case or is a "crutch".
It really is useful in the right scenarios, sure you shouldn't adopt it as your "official method for provisioning production servers" but that doesn't mean it doesn't have a legitimate use case or is a "crutch".
> Honestly, it sounds like an anti-feature or a crutch.
Every feature to one person can be a crutch to the next. Adding Salt or Chef to anything also increases the attack surface.
Every feature to one person can be a crutch to the next. Adding Salt or Chef to anything also increases the attack surface.
Ok those things are interesting though not killer level for me. But I moved away from Mac now because I found their stuff too opinionated. I use KDE now. I wonder if iTerm2 also exists on Linux if it's open source?
If you use KDE, then you already understand that having other peoples opinions forced on you doesn't always work.
You probably don't need iTerm because the KDE (and the Gnome tbh) consoles are so much better than the built-ins that come with Mac and Windows.
You probably don't need iTerm because the KDE (and the Gnome tbh) consoles are so much better than the built-ins that come with Mac and Windows.
Yes this is indeed exactly why I moved from Mac to KDE and why I donate to them. They still understand that in this day and age of opinionated design. I have KDE very heavily customised, but the cool thing is that unlike Gnome I didn't have to use a single plugin to do it (which always causes issues upgrading). Everything I wanted to change was available as a setting somewere.
And yeah I use Konsole, it's great! <3
MacOS wasn't so bad in the beginning, it used to be a Unix with good UI, but over the years Apple has been very busy replacing extensive settings with annoying on/off sliders (or nothing at all). Especially on macOS Server (if that's still a thing).
And yeah I use Konsole, it's great! <3
MacOS wasn't so bad in the beginning, it used to be a Unix with good UI, but over the years Apple has been very busy replacing extensive settings with annoying on/off sliders (or nothing at all). Especially on macOS Server (if that's still a thing).
I was gonna ask if Terminal never had any security issues, then tried to find a page with its release notes, and unfortunately couldn't find anything.
I also tried different macOS release notes [1][2][3][4], doing ctrl F "terminal" and could't find anything either.
Does anyone know where this is published? Is it not publicly available?
[1] https://developer.apple.com/documentation/macos-release-note...
[2] https://support.apple.com/en-us/120283
[3] https://support.apple.com/en-in/109035
[4] https://support.apple.com/en-us/106337
I also tried different macOS release notes [1][2][3][4], doing ctrl F "terminal" and could't find anything either.
Does anyone know where this is published? Is it not publicly available?
[1] https://developer.apple.com/documentation/macos-release-note...
[2] https://support.apple.com/en-us/120283
[3] https://support.apple.com/en-in/109035
[4] https://support.apple.com/en-us/106337
There definitely have been CVEs in Terminal.app, over many years:
- https://www.cve.org/CVERecord?id=CVE-2008-0042
- https://www.cve.org/CVERecord?id=CVE-2002-1898
- https://infocon.org/cons/Disobey/Disobey%202017/Mikko%20Kent... [video, I can't find a reference to that in Apple's release notes]
- There is also https://seclists.org/oss-sec/2018/q1/216 -- which led to a vague credit for Federico Bento in https://support.apple.com/en-ng/103758 proving they don't give everything CVEs (fine, but when the issue is public already it would be helpful to have a bit more detail).
I reported https://dgl.cx/2023/09/ansi-terminal-security#apple-terminal... to Apple ~2 years ago and they still haven't fixed it. It's not as serious as some vulnerabilities though and likely doesn't deserve a CVE, would be nice if they fixed it though.
(Finding this can be hard because Apple only link to release notes for currently supported versions, the pages are still around if you know the URL or you can find them via searches if they happen to be indexed still.)
- https://www.cve.org/CVERecord?id=CVE-2008-0042
- https://www.cve.org/CVERecord?id=CVE-2002-1898
- https://infocon.org/cons/Disobey/Disobey%202017/Mikko%20Kent... [video, I can't find a reference to that in Apple's release notes]
- There is also https://seclists.org/oss-sec/2018/q1/216 -- which led to a vague credit for Federico Bento in https://support.apple.com/en-ng/103758 proving they don't give everything CVEs (fine, but when the issue is public already it would be helpful to have a bit more detail).
I reported https://dgl.cx/2023/09/ansi-terminal-security#apple-terminal... to Apple ~2 years ago and they still haven't fixed it. It's not as serious as some vulnerabilities though and likely doesn't deserve a CVE, would be nice if they fixed it though.
(Finding this can be hard because Apple only link to release notes for currently supported versions, the pages are still around if you know the URL or you can find them via searches if they happen to be indexed still.)
So the only reason I switched to iTerm2 was because I wanted my terminal to change color when I ssh into different hosts. If I ssh into my work machine the terminal turns blue. If I ssh into my home machine the terminal turns purple. I'd tried to do this with the default terminal but ran into issues with it getting confused depending on how a session ended. People suggested iTerm2 because it supposedly solves this. And it does, at least for me.
How do you do this? Didn't know about this feature.
This! I've played with wezterm and ghostty but haven't been able to get this working there, so I keep coming back to iTerm2 for this exact feature - so that prod servers have a red background, etc.
Kitty (https://sw.kovidgoyal.net/kitty) has been my go to for many years and with tmux it's fantastic.
I have heard a lot of great things about https://ghostty.org/ but haven't had a chance to check it out
edit: oops, I misread your question as "what alternatives are there"
I have heard a lot of great things about https://ghostty.org/ but haven't had a chance to check it out
edit: oops, I misread your question as "what alternatives are there"
My only issue with kitty and tmux is that I always have to copy over my terminfo files manually or else I get a 'xterm-kitty': unknown terminal type error.
I've done the same, but in case you didn't know Kitty can do that automatically (though it does a bit more that you may or may not want it to do)
https://sw.kovidgoyal.net/kitty/kittens/ssh/
https://sw.kovidgoyal.net/kitty/kittens/ssh/
Kitty is really the only superior editor beyond ghostty terminal iterm weztwrm alacritty foot and others and the only one worth recommending.
No it's not. The author smuggles opt-out telemetry and is suspiciously abrasive towards users pointing this out.
https://github.com/kovidgoyal/kitty/pull/3544
https://github.com/kovidgoyal/kitty/pull/3544
No, he’s not. Calling this telemetry is a stretch and that’s his style on everything he disagrees with (unfortunately).
It would be a stretch if it was opt-out, but as it is, every installation of Kitty phones home by default. That is the exact equivalent of telemetry.
His "style" compounds on that by making him seem untrustworthy.
His "style" compounds on that by making him seem untrustworthy.
This, of course, depends on how long you’ve been using macOS and what long list of quirks you’ve acquired.
For me, „just” being able to use a full-screen-mode-that-is-different-than-native-macOS-full-screen is worth it; but I imagine there are maybe like seven other people out there for whom it matters.
For me, „just” being able to use a full-screen-mode-that-is-different-than-native-macOS-full-screen is worth it; but I imagine there are maybe like seven other people out there for whom it matters.
This is the only reason I use iTerm2. I can view the terminal full screen while also instantly switching to the browser or other windows, without the animation.
> full-screen-mode-that-is-different-than-native-macOS-full-screen
Thank you for reminding me why I should just return to iTerm! It might seem minor to some, but this is such an essential 'feature' that it probably overrides all other differences, for me.
One small question, though: are you aware of anything that 'native' full-screen does that 'bespoke' full-screen misses out on? Any disadvantages whatsoever?
Thank you for reminding me why I should just return to iTerm! It might seem minor to some, but this is such an essential 'feature' that it probably overrides all other differences, for me.
One small question, though: are you aware of anything that 'native' full-screen does that 'bespoke' full-screen misses out on? Any disadvantages whatsoever?
Full-screen-but-not-native is useful enough that it's handy to have around for all windows in all programs.
So the move there is to install Rectangle.app (https://rectangleapp.com/), the successor to Spectacle, and then choose your terminal independently.
So the move there is to install Rectangle.app (https://rectangleapp.com/), the successor to Spectacle, and then choose your terminal independently.
That’s not what iTerm2 does.
I want an actual-full-screen, with menu-bar and Dock invisible, with no window chrome - not merely “fill the maximum allowable space by the OS, as if dragging the windows corner with mouse”.
BUT I don’t want to use the native affordance for that, since that makes it its own “Desktop”, and I can no longer switch to it using my Snow Leopard-era muscle memory of using ^-<number> to switch between them.
I am fully aware that this is incredibly niche requirement, but it is a dealbreaker for me :)
I saw that Ghostty kinda supports this; but then disables tab support if this is enabled, which, also an obvious dealbreaker.
I want an actual-full-screen, with menu-bar and Dock invisible, with no window chrome - not merely “fill the maximum allowable space by the OS, as if dragging the windows corner with mouse”.
BUT I don’t want to use the native affordance for that, since that makes it its own “Desktop”, and I can no longer switch to it using my Snow Leopard-era muscle memory of using ^-<number> to switch between them.
I am fully aware that this is incredibly niche requirement, but it is a dealbreaker for me :)
I saw that Ghostty kinda supports this; but then disables tab support if this is enabled, which, also an obvious dealbreaker.
There are reasons. Whether they are compelling or not, largely depends on what software you want to run.
https://textual.textualize.io/FAQ/#why-doesnt-textual-look-g...
https://textual.textualize.io/FAQ/#why-doesnt-textual-look-g...
Instead, I would recommend Ghostty [1] terminal recently released v1.0 by one and only Mitchell Hashimoto of Hashicorp fame. It is OSS native cross-platform application (not an Electron one). I have been using it for the last year (private beta) on Mac and Linux and it rocks.
[1] https://github.com/ghostty-org/ghostty
[1] https://github.com/ghostty-org/ghostty
Could you post your config for inspiration? I dont like starting with a blank canvas.
It implements tmux control mode. It's very useful when working with a remote server.
No other terminal implements it AFAIK.
No other terminal implements it AFAIK.
What does tmux control mode do in practice? I use both (iterm2 and tmux), but not for this specific reason. I have just used both as a default for a long time.
So, what magic am I using without realizing it?
So, what magic am I using without realizing it?
tmux metaphors are implemented in gui. tmux tabs are iterm2 tabs, tmux windows are iterm2 windows, etc. attach/detach and so on will restore layouts.
i believe the session can even be shared with a normal tmux session.
i believe the session can even be shared with a normal tmux session.
Yes, this was such a nice feature when I used a Mac. And indeed the session seamlessly works as a normal tmux session. I believe WezTerm does tmux-style terminal multiplexing, but doesn't integrate with tmux.
I use the graphics support for making quick & dirty scrips for managing images (mostly for checking labeling and things like that where I don't want to bother creating a full web UI).
I tried Ghostty for this but couldn't get the images to display as quickly or in full resolution, but it's very possible I was holding it wrong. I'd love to switch, honestly, if anyone has a recommendation for how to make it work as well as the iterm2-tools Python package.
I also use multi-pane mirroring for managing some machines at home that I haven't bothered making more automated.
I tried Ghostty for this but couldn't get the images to display as quickly or in full resolution, but it's very possible I was holding it wrong. I'd love to switch, honestly, if anyone has a recommendation for how to make it work as well as the iterm2-tools Python package.
I also use multi-pane mirroring for managing some machines at home that I haven't bothered making more automated.
I use it primarily for its split pane functionality. Invaluable if you need to see multiple things happening on the same machine at once. I work in data science and often have several long running jobs on a single server, a notebook server, htop/iotop, nvidia-smi, or simply just having different panes cd'd to different directories - with iterm you can organise to a single terminal tab for each machine (including local), or group tabs across machines if they are for related work.
Have you tried using tmux?
Yes I use them together, iterm has a great tmux integration. Tmux vanilla does not have great UX (in my opinion).
native Terminal.app doesn't have true color support (24 bit colors). I was happy using it but wanted to try some fancy vim themes.
I stopped using iterm after it did the chatgpt integration, which was a bridge too far for my tastes and landed on wezterm. All of the alternatives have nits.
I stopped using iterm after it did the chatgpt integration, which was a bridge too far for my tastes and landed on wezterm. All of the alternatives have nits.
It's dumb, but Terminal.app is about eight years behind every other macOS terminal in supporting true color mode. Feels like sort of a table stakes feature in a modern terminal, and makes me suspect Terminal.app is not a high priority for Apple. The people want pretty editor themes!
It’s abandonware at this point. Even Windows Terminal is better now which is just embarrassing.
Same. I switched to Alacritty and later Ghostty.
I just have been trying ghostty recently - the biggest usability issue I’ve immediately run into is a lack of cmd-f to search text (as far as I can tell) —— I’m having to copy everything into a text editor then search. I never realized how often I used that it until I lacked it.
[deleted]
I got tired of weird sketchy seeming behavior in iterm2 (it'd hang randomly when accidentally sending binary streams to stdout; it'd take forever if I asked it to search my many tb of buffer, etc). I switched to xquartz and xterm, which was fine; I had to retrain my fingers back to whatever they'd been trained to do in 1998, but they got there.
But probably that's terrible advice for 99.8% of people out there, probably more like 99.998, or even more 9s.
But probably that's terrible advice for 99.8% of people out there, probably more like 99.998, or even more 9s.
I like the highly configurable quake mode in iTerm2.
Both are very competent terminal emulators. Just use either and you won’t miss much. I started using iTerm before the Terminal.app redesign (which was very much needed) and kept using it mostly for the tmux integration (which is a strong reason to use it). Nowadays, I would be happy using either. Ghostty is fine as well, though not as polished yet.
Control-tab can be set to cycle through tabs in recency order rather than the bad apple default of "go to the next tab to the right".
It has far too much feature bloat though to the point that it's somewhat brittle, and I'd imagine there are many more lurking security issues
It has far too much feature bloat though to the point that it's somewhat brittle, and I'd imagine there are many more lurking security issues
I just like having it docked to the top of my screen, and accessible via a global shortcut.
I'm sure there's a thousand others that do both of those things, but I adopted iTerm2 about 10 years ago, and it hasn't given me cause to investigate others.
I'm sure there's a thousand others that do both of those things, but I adopted iTerm2 about 10 years ago, and it hasn't given me cause to investigate others.
When I’m forced to use something else, I miss eternal-terminal atop tmux control mode and iterm. It’s total bliss and there’s no other terminal emulator on any platform that can compare.
If the stock terminal app supported more colors (idk what the official term is lol) I’d be fine using it. I don’t use any fancy iterm features anyway. Fish + zellij is all I need!
I stepped back into macOS for the first time in ~8 years and was disappointed by Terminal. To be honest, I think Windows Terminal is much better, which feels a bit weird to say.
Terminal came out 23 years ago, Windows Terminal in 2019. The old Windows terminal was garbage.
I still prefer the blurred transparency of Terminal over the too transparent Windows Terminal, but that’s a matter of taste.
I still prefer the blurred transparency of Terminal over the too transparent Windows Terminal, but that’s a matter of taste.
Hey, Terminal.app's been around ever since NeXTSTEP was born. Make it 35 years?
Pretty sure if it gets upgraded to become more modern somebody somewhere will also complain about it losing its simplicity.
Mitchell Hashimoto and group of contributors released a native terminal app recently - ghostty.org
Well suited replacement for iterm2 and terminal.app, imo
Well suited replacement for iterm2 and terminal.app, imo
> strongly compelling reasons to use [3rd-party terminal]
Deniable ("popular app") increase in attack surface?
Deniable ("popular app") increase in attack surface?
Copy on select is the feature I used to over the years (on BSD/Linux) and stock Terminal lacks it.
Two main reasons I switched is that iTerm can actually display bitmap fonts without mangling them (Terminal has anti-aliasing always on) and that it handles the difference between left and right Alt (needed because AZERTY layout + emacs).
>Terminal has anti-aliasing always on
There's a setting under Profiles/Text in the Text section. It's the first checkbox. Does that work, or is there a bug?
There's a setting under Profiles/Text in the Text section. It's the first checkbox. Does that work, or is there a bug?
I am using bitmap font with AA off in Terminal.app so this is incorrect
Tmux
tmux runs just fine in Terminal.app. What else, then?
I feel deeply for the developer who develops iTerm for relatively very little money, and already took a lot of criticism for the AI integration, far more than was warranted.
I am also also deeply concerned about my use of iTerm now.
I access HPC environments where I may have access for a short period of time. I am expected to take responsibility to clear out my data after use and don't expect there to be any data leakage. If I had been manipulating PII research data in the past year and using iTerm's SSH integration I would be in a bit of a bind and have to send some really embarrassing emails asking sysadmins to see if these logs exist, and if they belong to me, followed by disclosing data had been leaked.
I use some of the more advanced features but at this point wonder if I should be using any features beyond the basic, and then I may as well be using another terminal. I haven't found a cross-platform editor that feels as native on MacOS as iTerm, ghostty included.
I am also also deeply concerned about my use of iTerm now.
I access HPC environments where I may have access for a short period of time. I am expected to take responsibility to clear out my data after use and don't expect there to be any data leakage. If I had been manipulating PII research data in the past year and using iTerm's SSH integration I would be in a bit of a bind and have to send some really embarrassing emails asking sysadmins to see if these logs exist, and if they belong to me, followed by disclosing data had been leaked.
I use some of the more advanced features but at this point wonder if I should be using any features beyond the basic, and then I may as well be using another terminal. I haven't found a cross-platform editor that feels as native on MacOS as iTerm, ghostty included.
I highly recommend wezterm.
I tried WezTerm recently but I unfortunately could not type backslashes on an ISO keyboard. There were other minor annoyances such as new tabs always opening on the last directory I was at and not my home directory (this was something that could be configured, but I never managed to do it). Ultimately, it was the problem with the backslashes that drove me back to iTerm.
https://github.com/wez/wezterm/issues/4051
https://github.com/wez/wezterm/issues/4051
Ghostty, Alacritty and Kitty are also very good options
Why switch to another terminal, after 1 issue, in all this time since it exists?
It’s like throwing away your car after having a flat tire… perhaps iTerm is still the best option available, considering all the plus points / features it has.
It’s like throwing away your car after having a flat tire… perhaps iTerm is still the best option available, considering all the plus points / features it has.
Fwiw, it's not your responsibility to maintain a secure computing environment (assuming you're a researcher). If you, personally, have to vet the whole system and all the software you use for security, then they have none.
A competent system administrator with a knowledge of system security can easily configure a host so that when you SSH in, files you create are not given world-readable permissions by default. They can add other lock-down mechanisms that isolates all the users' files entirely. And they can simply disable all world-writeable folders like /tmp/.
So in case anyone gives you (or anyone else) a load of crap about using insecure software, ask them why their systems are so insecure.
A competent system administrator with a knowledge of system security can easily configure a host so that when you SSH in, files you create are not given world-readable permissions by default. They can add other lock-down mechanisms that isolates all the users' files entirely. And they can simply disable all world-writeable folders like /tmp/.
So in case anyone gives you (or anyone else) a load of crap about using insecure software, ask them why their systems are so insecure.
I assume you never worked in academia. Sometimes hpc are installed by researchers (incl myself) as there is no budget for IT staff.
Still not your responsibility. If they don't cough up the cash to properly manage the security, they can't expect any. Just because a trucking company doesn't want to pay for a mechanic, doesn't mean they can expect their drivers to repair blown engines.
Most of the time
- all input ports are blocked. Kinda provides security. Works fine as if things are so dire most academia would be hacked.
- these are not valuable like data from SSN or bank. So fewer attacks.
- if something gets f*ked - it gets bad name - people laugh it off. No one will get fired.
I know uni presidents that keep passwords on excel sheets. Life is like that.
Let's be honest corporate says training, retraining, testing - IT will install 3 different malware scanners and 2 AV to HOG CPU etc but some idiot will approve MFA/TOTP (okta) or like solarwinds. So everyone has their stupidity.
- all input ports are blocked. Kinda provides security. Works fine as if things are so dire most academia would be hacked.
- these are not valuable like data from SSN or bank. So fewer attacks.
- if something gets f*ked - it gets bad name - people laugh it off. No one will get fired.
I know uni presidents that keep passwords on excel sheets. Life is like that.
Let's be honest corporate says training, retraining, testing - IT will install 3 different malware scanners and 2 AV to HOG CPU etc but some idiot will approve MFA/TOTP (okta) or like solarwinds. So everyone has their stupidity.
I use Prompt by Panic.
from the App store, the only place where you can get this app...
Not to mention the exorbitant price for a lifetime license.
Location
This app may use your location even when it isn't open, ...
Not to mention the exorbitant price for a lifetime license.
> why would a terminal emulator need my location
Because that's the only way Apple allows apps to stay open in the background on iOS so your SSH connection doesn't disconnect after 10 minutes. And the Mac app is a universal app with iPhone/iPad so it has the same permissions. If you never enable the "Connection Keeper" feature it never requests the permission.
Because that's the only way Apple allows apps to stay open in the background on iOS so your SSH connection doesn't disconnect after 10 minutes. And the Mac app is a universal app with iPhone/iPad so it has the same permissions. If you never enable the "Connection Keeper" feature it never requests the permission.
Thanks for this, I was unaware of that fact. TIL.
It's really unintuitive!
A lot of photo sync apps also have to use this workaround to be able to sync your photos in the background, it's been a long-standing issue with Apple's platform.
And App Store rules means they have to justify the location permissions so they add a totally unrelated "make a log of your location throughout the day!" feature in the app just to get App Review to approve it, even though everyone knows that's not actually why they need it.
A lot of photo sync apps also have to use this workaround to be able to sync your photos in the background, it's been a long-standing issue with Apple's platform.
And App Store rules means they have to justify the location permissions so they add a totally unrelated "make a log of your location throughout the day!" feature in the app just to get App Review to approve it, even though everyone knows that's not actually why they need it.
[deleted]
winaiisbest(2)
winaiisbest(2)
Many years ago, I reported an issue where iTerm2 leaks sensitive search history to preference files [1]. The issue was quickly fixed. But until this day, I can still find people unintentionally leak their search history in public dotfiles repos [2].
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
I’m a bit confused by the suggestion to "Just don’t use iTerm2." The reality is that this type of issue could happen with any project, and switching tools doesn’t provide meaningful protection. If anything, incidents like this often lead to stronger security practices. It’s like the old joke about firing an engineer after a mistake, and the manager responding, "Why would I fire them? They’ve just learned a lesson they won’t forget." Based on iTerm2’s track record, it doesn’t seem like they’ve had frequent critical security issues, and I doubt they’ll repeat this mistake. If they do, then it’s fair to reassess.
As for the MacOS Terminal app, it might seem like a lower-risk option because it’s simpler and updates less frequently. However, being closed-source makes it impossible to audit, which brings its own risks. Ultimately, every tool has tradeoffs, and choosing the right one depends on balancing your needs with the potential risks.
As for the MacOS Terminal app, it might seem like a lower-risk option because it’s simpler and updates less frequently. However, being closed-source makes it impossible to audit, which brings its own risks. Ultimately, every tool has tradeoffs, and choosing the right one depends on balancing your needs with the potential risks.
> could happen with any project, and switching tools doesn’t provide meaningful protection
Do you believe that developments practiced have an impact on security bug rate? Second, do you believe that past track record is reflective of that security bug rate?
These are two reasonable beliefs that many people hold. It's a far more nuanced view than "every project could have bugs" which is a black-and-white view that does not assess risk in a useful way.
Do you believe that developments practiced have an impact on security bug rate? Second, do you believe that past track record is reflective of that security bug rate?
These are two reasonable beliefs that many people hold. It's a far more nuanced view than "every project could have bugs" which is a black-and-white view that does not assess risk in a useful way.
iTerm2 increasingly seems too complex and bloated to me, with too many security issues. I haven't shopped for a new terminal emulator on macOS in a long time, but perhaps it's now time.
I should also get around to switching to tmux, now that GNU Screen seems to be stagnant...
I should also get around to switching to tmux, now that GNU Screen seems to be stagnant...
I recently gave Ghostty a chance and have since switched over from iTerm2 completely. It's very familiar and polished.
Probably worth noting that Ghostty was very recently vulnerable to an old/familiar class of terminal vuln that bit a bunch of older terminal applications a while back: https://dgl.cx/2024/12/ghostty-terminal-title
So moving to a newer / less "bloated" terminal may also just wind the clock back and cause you to encounter a similar sequence of vulns again, like some kind of unfortunate real-world "New Game Plus".
So moving to a newer / less "bloated" terminal may also just wind the clock back and cause you to encounter a similar sequence of vulns again, like some kind of unfortunate real-world "New Game Plus".
Having a vuln that many other terminal emulators have had is pretty different from the string of unique and extremely bad vulns that iTerm has had over the years. It’s possible that we’ll see similar from Ghostty, but it’s a much newer and I believe smaller codebase, so I’m willing to give it a second chance.
I've been using iTerm daily for something like a decade at this point and I'm struggling to think of any examples of this string of extremely bad vulns. There's this one, which is specific to SSH integration. There was CVE-2024-38396, which is the window title escape sequences I was talking about above.
What others am I missing?
What others am I missing?
How about making DNS requests for everything you hover over to determine if it’s a URL? https://www.bleepingcomputer.com/news/security/iterm2-leaks-...
A vuln every 7-8 years is "a string of unique and extremely bad vulns"?
I use iTerm2, mostly because that's what I'm used to: I installed it on my first Mac years ago when Terminal.app was really bad. I'm willing to switch to another terminal, but I don't see yet how iTerm2 is so much worse than the competition security-wise.
(I also don't understand the general animosity towards an opensource project with one developer doing all the work for 15 years.)
I use iTerm2, mostly because that's what I'm used to: I installed it on my first Mac years ago when Terminal.app was really bad. I'm willing to switch to another terminal, but I don't see yet how iTerm2 is so much worse than the competition security-wise.
(I also don't understand the general animosity towards an opensource project with one developer doing all the work for 15 years.)
> A vuln every 7-8 years is "a string of unique and extremely bad vulns"?
Here’s another: https://www.bleepingcomputer.com/news/security/iterm2-patche...
And another: https://www.cvedetails.com/cve/CVE-2019-19022/
Point being: it’s not hard to see what I’m talking about if you look up previous vulnerabilities in iTerm2, particularly around its sophisticated integration features. (I suppose I talk about this enough that it might be worth compiling all the history I’m aware of somewhere, I don’t want to sound like I’m just making this up)
It’s also notable that iTerm was found vulnerable to the same bug discovered recently in Ghostty: https://threatintelligencelab.com/blog/cve-2024-38396-a-crit...
> I also don't understand the general animosity towards an opensource project with one developer doing all the work for 15 years
I have nothing against George Nachman and iTerm2 is certainly an achievement, one that I probably couldn’t replicate myself. Nonetheless I feel the need to hold my terminal emulator to higher standards because it processes sensitive data and untrusted input with (inherently) poor isolation between the two. Until Ghostty I used Terminal.app for many years, having previously switched away from iTerm2 after the vulnerability discovered in 2017. That’s still what I recommend to people because it has a much smaller feature set and thus attack surface compared to iTerm.
Here’s another: https://www.bleepingcomputer.com/news/security/iterm2-patche...
And another: https://www.cvedetails.com/cve/CVE-2019-19022/
Point being: it’s not hard to see what I’m talking about if you look up previous vulnerabilities in iTerm2, particularly around its sophisticated integration features. (I suppose I talk about this enough that it might be worth compiling all the history I’m aware of somewhere, I don’t want to sound like I’m just making this up)
It’s also notable that iTerm was found vulnerable to the same bug discovered recently in Ghostty: https://threatintelligencelab.com/blog/cve-2024-38396-a-crit...
> I also don't understand the general animosity towards an opensource project with one developer doing all the work for 15 years
I have nothing against George Nachman and iTerm2 is certainly an achievement, one that I probably couldn’t replicate myself. Nonetheless I feel the need to hold my terminal emulator to higher standards because it processes sensitive data and untrusted input with (inherently) poor isolation between the two. Until Ghostty I used Terminal.app for many years, having previously switched away from iTerm2 after the vulnerability discovered in 2017. That’s still what I recommend to people because it has a much smaller feature set and thus attack surface compared to iTerm.
I hope I didn´t sound like I did not believe you, I honestly had no idea. I don´t get an update for iTerm2 every week so I figured it was mostly stable / had no sec issue.
Following this discussion I decided to give Ghostty and kitty a try. I kept Ghostty, mainly because the shortcuts I use the most in iTerm2 are there and I like the default theme (yes, I'm a simple person.) It has less features / integrations I don´t use anyway so I guess the attack surface is smaller.
Following this discussion I decided to give Ghostty and kitty a try. I kept Ghostty, mainly because the shortcuts I use the most in iTerm2 are there and I like the default theme (yes, I'm a simple person.) It has less features / integrations I don´t use anyway so I guess the attack surface is smaller.
ahefner(1)
I can only find three CVEs prior to this. It's only one of those that I would qualify as "extremely bad" (the DNS query leak you mention below). The others are the window title bug GP mentions and the undocumented maintenance of a plain text search history file.
Ghostty has also been out for what, a week? So this is the open season / shakedown, when security researchers get to try out all the old favorites and see what got missed.
I don't think there are larger lessons to draw from that occurrence. A reputation for security has to be earned, and Ghostty hasn't been around long enough for that. From my vantage point it's on track, but only time will tell.
I don't think there are larger lessons to draw from that occurrence. A reputation for security has to be earned, and Ghostty hasn't been around long enough for that. From my vantage point it's on track, but only time will tell.
I'm not trying to knock either Ghostty in particular or new software in general. But the kind of "open season" phase you're referring to is basically the same point I'm making: new software still has to go through the phase where they work through their security model, have it probed by researchers, and earn their reputation.
Unfortunately, it's nowhere near close feature-wise just yet: proper quake mode, search, prompt navigation, line timestamps, tab output indicators, forced keyboard locales, customizable toolbar with user-defined variables/indicators, are all too useful to give up iTerm2 for anything.
What is "proper Quake mode"? Have you tried https://ghostty.org/docs/config/keybind/reference#toggle_qui...? (I don't have the habit to use this feature, but I'd like to!)
The others do sound useful too -- I personally hit a lot of spurious "tab output indicator" notifications in iTerm2, but if it _did_ work I could see how giving it up would be painful.
The others do sound useful too -- I personally hit a lot of spurious "tab output indicator" notifications in iTerm2, but if it _did_ work I could see how giving it up would be painful.
Proper quake mode is just one shortcut to show/hide the entire terminal window, otherwise the app is completely hidden from the app switcher and the dock. This also involves handling macOS keyboard-to-app layout mapper not reacting to this event as the window loses its first-class citizen status in this mode.
I got the toggle working, but couldn't get background transparency.
I tried iTerm’s quake mode after the Visor haxie for Terminal.app was shuttered, but unfortunately was left disappointed. Its behavior is kinda glitchy and inconsistent in comparison, which was surprising because one would expect a native feature to be better than one hacked in by a third party, but that was not the case here.
I tried Ghostty earlier in the week, but couldn’t get it set up to look the same as iterm2 (the colours are off and text looks different somehow with the same typeface at the same size). Which is just cosmetic but makes it feel wrong viscerally.
I’ll give it another go at the weekend.
I’ll give it another go at the weekend.
Somehow this is the first time I see anyone else bring this up, but the fonts are absolutely displayed with wrong kerning on my mac, for my font (at 12pt) I was able to make it look the same as iTerm2 with adjust-cell-{width,height} both set to -5%.
I had an issue where Ghostty failed to render the text "th", so I think Ghostty just generally has a lot of font issues. Gave up trying to use it within minutes.
It seems that I had iTerm2 configured to display bold text as bright text (instead of bold). And I use bold, coloured text in my prompt, so that threw me.
I configured
https://ghostty.org/docs/config/reference#bold-is-bright
I configured
bold-is-bright = true
https://ghostty.org/docs/config/reference#bold-is-bright
I noticed the colors looked off when I was trying out Ghostty as well. Adding this line to my config fixed it after restarting the app: `window-colorspace = display-p3`
https://ghostty.org/docs/config/reference#window-colorspace
https://ghostty.org/docs/config/reference#window-colorspace
Ghostty supports iTerm themes, so you should be able to transfer your preferred look-and-feel directly. I just picked one I liked, so I'm not familiar with the process, but it can be done.
Could you please point to the docs about how to transfer iTerm2 themes to Ghostty? I couldn't find it.
It looks like the process is more manual than I thought, sorry. There's something which imports themes from the iTerm2 color schemes website weekly, but from what I can find that isn't a feature which ships with Ghostty itself.
Here's the relevant docs page, which I hope explains why I mistakenly thought that transferring a theme directly from iTerm to Ghostty was possible. You could upload your theme to the website they're being sourced from, and wait a week. But that's clearly not the same thing.
https://ghostty.org/docs/features/theme
Here's the relevant docs page, which I hope explains why I mistakenly thought that transferring a theme directly from iTerm to Ghostty was possible. You could upload your theme to the website they're being sourced from, and wait a week. But that's clearly not the same thing.
https://ghostty.org/docs/features/theme
I used font-thicken = true and it looks pretty good, very similar to iTerm.
I am using both at the moment, but iTerm has many, many features missing in ghostty. Most of them are not huge, but overall that’s a lot of paper cuts. Ultimately I wish both will stick around. Both have good ideas and I’d like them to keep evolving.
I tried Ghostty but the configuration file seems to be flakey. For example I wasn't able to turn off the cursor blinking in it (huge distraction for me) despite there being a configuration flag for it, it just wouldn't take it.
There's a known issue where the shell integration doesn't respect that setting when it sets the cursor shape. https://github.com/ghostty-org/ghostty/discussions/2812
Have you tried shell-integration-features = no-cursor ?
I also switched over to Ghostty, but now can't do Cmd+F to search for strings, I think it's on the roadmap though. Also, there are no scroll bars on the Mac version, which I guess is not that important for a terminal.
I did the same. Although, Ghostty doesn't seem to have support for Find (⌘-F), yet. Also, had some minor hiccups with it and tmux on remote hosts.
I've resorted to using Cmd-Shift-J (scrollback buffer) and grepping that, but its flaky about whether it will honor the command and emit a history file.
I tried Ctrl+r while she'd and it didn't work. Otherwise ghosty looked great
Does Ghostty support natural text editing like iTerm2 does?
Same. So far so good.
> It's very familiar...
It is? Because as far as I can tell it is deliberately quite different from iTerm2. No GUI for preferences, for instance.
Not knocking it, it's a great terminal. I wouldn't describe it as "familiar" though, unless you're switching from, say, WezTerm or Alacritty.
It is? Because as far as I can tell it is deliberately quite different from iTerm2. No GUI for preferences, for instance.
Not knocking it, it's a great terminal. I wouldn't describe it as "familiar" though, unless you're switching from, say, WezTerm or Alacritty.
Ghostty hasn't had to put out a critical update since before 1.0 launched.
I'm a heavy use of tmux integration in iterm2. this allows seamless mouse scroll in a tmux window. I haven't seen any other terminals that provide the same tmux support.
Wezterm doesn’t have tmux integration but instead implements multiplexing natively, meaning if you install it on a remote, it will host a mux server you can attach to over ssh. Pretty cool, and much faster/lower latency than tmux.
I have used Terminal.app since 10.0, and have never felt like it needed replacing. What is lacking in Terminal that would improve my day to day by using a different app?
That's a question that only you can answer. We have no idea what your average terminal activity involves.
(I can't remember why I switched. It must have been 10 years ago now, maybe more, and I've stuck with iTerm2 ever since (even though it annoys me with a new beta update practically every time I launch it). It could have been nothing fancier than the vertical window split. But there was definitely something that persuaded me to change!)
EDIT: this did get me wondering, and I noticed two things it does have that it looks like Terminal still doesn't: configurable mouse selection word boundary chars, and implicit copy-to-clipboard on selection. As an inveterate mouse selector, I wonder if it was these. I might well actually have the word boundary chars still set to the default ("/-+\~_." is what I've got), but I do use the click-to-copy a lot.
(I can't remember why I switched. It must have been 10 years ago now, maybe more, and I've stuck with iTerm2 ever since (even though it annoys me with a new beta update practically every time I launch it). It could have been nothing fancier than the vertical window split. But there was definitely something that persuaded me to change!)
EDIT: this did get me wondering, and I noticed two things it does have that it looks like Terminal still doesn't: configurable mouse selection word boundary chars, and implicit copy-to-clipboard on selection. As an inveterate mouse selector, I wonder if it was these. I might well actually have the word boundary chars still set to the default ("/-+\~_." is what I've got), but I do use the click-to-copy a lot.
There's a mini-renaissance going on with new terminal tools, like tmux, neovim (which has an ecosystem of plugins itself), htop, and many more (https://github.com/rothgar/awesome-tuis). They take greater advantage of 24-bit color, "nerd" fonts (that have icons for glyphs), some graphics capability, and so on.
I used Terminal for many years, too, but switched to iTerm2 a little over a year ago as I wanted to learn neovim.
I used Terminal for many years, too, but switched to iTerm2 a little over a year ago as I wanted to learn neovim.
In my opinion, the most notable feature missing from Terminal.app is 24-bit color support. This is a standard feature in modern terminal emulators, and is one that I enjoy very much. But for many people, that is not a feature that makes a big difference.
For me it’s 3 major things:
- split pane support - profile switching (I have my colors change for different environments I ssh into). - tmux integration
- split pane support - profile switching (I have my colors change for different environments I ssh into). - tmux integration
Still use GNU Screen? Both GNU Screen and tmux had security issues in past, but GNU Screen had worse ones and that is why I switched. Zellij is a Rust terminal multiplexer, might wanna look into that. What I especially love about it, is tge discoverability of the keybinds. TUI wet dream.
I don't use Mac but what's wrong with the default?
> GNU Screen seems to be stagnant
Is it stagnant or mostly complete?
> GNU Screen seems to be stagnant
Is it stagnant or mostly complete?
> I don't use Mac but what's wrong with the default?
Nothing, it works great. As someone who tried a bunch of alternatives: sorry but it's a waste of time unless you look at the long list of iterm2 features (terminal.app has many of them anyway) and think you might use those often (I don't, quite happy with my other apps covering for most of the features missing from the terminal.app): https://iterm2.com/features.html
Nothing, it works great. As someone who tried a bunch of alternatives: sorry but it's a waste of time unless you look at the long list of iterm2 features (terminal.app has many of them anyway) and think you might use those often (I don't, quite happy with my other apps covering for most of the features missing from the terminal.app): https://iterm2.com/features.html
Complete I would say. However Mac uses GNU software from around 2006, since around that time a lot of GNU software switched from GPLv2 to GPLv3.
That means Mac ships GNU screen version 4 from 2006, while latest version is 5.
v4 2006: feature complete, survived 18 years of attacks
v5 2024: new auth functionality, survived 4 months of attacksI try out the new apps each year and always go back to Terminal.app. My one gripe with it was that Opt-Del didn't delete words, which I learned last year can be fixed by Preferences > Profiles > Keyboard > Use Option as Meta key
Long live Terminal.app
Long live Terminal.app
I've considered "screen" complete since I started using it over 30 years ago.
I recently ran into a bunch of problems running neovim under GNU Screen with `TERM=screen.xterm-256color`. There was some kind of problem relating to GNU Screen's parsing and re-transmit of certain full-color terminal escape codes. I don't remember the details right now, but what I know is that building the latest from source didn't help. (I wish I could remember the specific issues)
[deleted]
I’ve been using tmux for over a decade because screen was a bit on the legacy side back then
> GNU Screen seems to be stagnant...
Not at all, it just had a release a few months ago,
GNU Screen v.5.0.0 is released posted by anaumov, Wed 28 Aug 2024 09:41:30 PM UTC
Not at all, it just had a release a few months ago,
GNU Screen v.5.0.0 is released posted by anaumov, Wed 28 Aug 2024 09:41:30 PM UTC
Would xpipe be a candidate? It’s also quite feature packed, but i was pleasantly surprised how nicely it got out of my way
> now that GNU Screen seems to be stagnant...
That's not a new thing...
That's not a new thing...
What else does it need?
I get old code smell, and why folks might want something architecturally different, whatever - but screen is functionally feature complete.
I get old code smell, and why folks might want something architecturally different, whatever - but screen is functionally feature complete.
I haven't looked super hard, but an iTerm feature I "gotta have" is triggers - regexps that match lines of text in the terminal and do an action.
You can do some complex stuff with them, but I "just" use them to highlight specific things when tailing output. Some of it might be possible with grep, but probably not
You can do some complex stuff with them, but I "just" use them to highlight specific things when tailing output. Some of it might be possible with grep, but probably not
I really like alacritty + tmux, personally.
I switched to Warp, much snappier, some AI features, overall very good experience. Also Ghostty is apparently good.
This was only for the SSH integration, not if you just ran "ssh" in iTerm? I don't see these /tmp/framer.txt files on any of the hosts I sshed to (plain ssh).
From the release notes it seems only if the in-built SSH integration was used and the server that a more recent (5ish year old or later) version of Python. The latter condition is probably going to exist even on enterprise dists (RHEL 9 for example will have Python 3.9 installed by default)
The latter condition must not always trigger... I have Python 3.7 or later and none of my servers have a `/tmp/framer.txt` file.
[deleted]
This thread reminded me to make my annual donation to iTerm2's developer, who does a pretty amazing job keeping iTerm MacOS compliant and up to date.
If one is already in the GitHub sponsors ecosystem, he accepts those too https://github.com/sponsors/gnachman
This thread reminded me to make a donation as well!
Just did the same. I've used this app for years and benefitted from its features. It's a shame to see some of the comments in this thread.
> Delete /tmp/framer.txt on affected hosts.
Isn’t the correct fix to assume compromise and rotate all SSH keys? I imagine there will be scripts created very quickly to grab this file from any servers, so even if it is deleted soon there is no guarantee someone else has not read it.
Isn’t the correct fix to assume compromise and rotate all SSH keys? I imagine there will be scripts created very quickly to grab this file from any servers, so even if it is deleted soon there is no guarantee someone else has not read it.
I'm not sure I follow. From what I understand, the issue is that literally all of stdin and stdout is potentially leaked to a globally-readable text file. ssh-keys wouldn't normally be part that leaked information (other than if you `cat` your private key, but by that logic, literally any credentials ever stored in a file or potentially even an env var would be equally susceptible). Yes, anyone with ssh access would have access, but nothing about this vulnerability seems to imply it would allow an unauthorized user to gain ssh access. It doesn't sound like this is something with a specific risk of leveraging into ssh access because the only ones who can read the file are the ones with access in the first place, so there's no more reason to suspect that now compared to any other point in time.
Agreed. I believe this means just means that the entire contents of your ssh session is available in /tmp/framer.txt. But as long as credentials aren't part of your STDIN/STDOUT, then they shouldn't be leaked.
Your ssh private key definitely would never be in there. The server you're connecting to doesn't even know your private key, just the public one.
Your ssh private key definitely would never be in there. The server you're connecting to doesn't even know your private key, just the public one.
So Sudo password for example seem to be up there.
That's an interesting point; I think it might depend on the exact details of how stuff is getting put into that tempfile. It's possible that anything getting read in via "silent mode" (see `-s` in https://ss64.com/bash/read.html) might not get put into that file, but given that this was a bug rather than a feature, it would probably be better to check the source code (or try an example with an unpatched version) to be sure.
> A bug in the SSH integration feature caused input
and output to be logged to a file on the remote
host. This file, /tmp/framer.txt, may be readable
by other users on the remote host.
Curious about how this happens. What does "framer" mean, here?
Curious about how this happens. What does "framer" mean, here?
Here's the commit where it was reversed, if you want to take a look and dive in. Looks like unfortunately a logging feature that he has was set to 1 instead of 0 and wasn't reset before compiling.
https://gitlab.com/gnachman/iterm2/-/commit/014ba7ec40fc790f...
https://gitlab.com/gnachman/iterm2/-/commit/014ba7ec40fc790f...
Sounds like something dropped in the code for debugging purposes and accidentally released.
On the bright side this made me realize the stock terminal app has improved. I do use iTerm2 for its better rendering of text and color (and easier configuration of those things) but I don't really make use of any other features. Time to switch, perhaps.
iTerm2 is the app I spend the most time for like a decade or so.
I feel bad for the developer. This is embarrassing and it totally could and probably will at some point happen to the best of us.
So I have immediately donated and subscribed to monthly donations and I encourage everyone to do so. There should be zero doubt that the author deserves our support.
I feel bad for the developer. This is embarrassing and it totally could and probably will at some point happen to the best of us.
So I have immediately donated and subscribed to monthly donations and I encourage everyone to do so. There should be zero doubt that the author deserves our support.
Why does a terminal need an SSH integration. Answer: it doesn’t and you shouldn’t use this because it is unsafe.
A terminal doesn't need SSH integration, but it's convenient if it does, to allow you to easily start and manage connections. Is there something inherently unsafe about such an integration?
There's something inherently unsafe with replacing an industry-standard security tool with anything.
I don't think it's inconvenient enough to type `ssh -i key_file name@host` that we need to be creating more security risk to skip typing it.
I don't think it's inconvenient enough to type `ssh -i key_file name@host` that we need to be creating more security risk to skip typing it.
> I don't think it's inconvenient enough to type `ssh -i key_file name@host` that we need to be creating more security risk to skip typing it.
Also, you can easily configure that in your .ssh/config file, even with different options per host or group of hosts.
Also, you can easily configure that in your .ssh/config file, even with different options per host or group of hosts.
That sound you hear is IT admins worldwide scrambling to delete /tmp/framer.txt from all their servers.
I would love to know more about how this got discovered and figured out. I can imagine some sysadmin pull their hair out, thinking they've got some infected system, but then find out it was some bug with their terminal emulator.
> got discovered and figured out
Unapproved usage of the exploit?
Unapproved usage of the exploit?
I would advice anyone using iTerm not to willy-nilly switch their terminal to one recommended by a random user here.
Terminals can have a huge attack surface and many "open-source" ones are maintained by less than trustworthy developers who very easily could inject a backdoor.
Sticking with time-proven projects like iTerm provides the advantage of added trust, security and basic common sense.
It also seems like a huge coincidence that there are a lot of green accounts here "highly" recommending all sorts of random terminal alternatives.
Terminals can have a huge attack surface and many "open-source" ones are maintained by less than trustworthy developers who very easily could inject a backdoor.
Sticking with time-proven projects like iTerm provides the advantage of added trust, security and basic common sense.
It also seems like a huge coincidence that there are a lot of green accounts here "highly" recommending all sorts of random terminal alternatives.
How does a bug like this last for so many months without being noticed? Did no one notice a weird file in /tmp and wonder where it came from? The one with their ssh session history in it?
Given the purpose of the /tmp directory it seems an unlikely source for one's afternoon reading. I wonder what % of iTerm2 users use this integration feature as well. I didn't even know it existed.
Perhaps not that many people were using `itssh` or replaced the initial profile command with SSH + SSH integration.
It sounds like a rarely used feature of iTerm2. I have not even heard of it despite using iTerm2's shell integration and tmux integration for a long time until I switched to Linux.
I've used iTerm2 for as long as I've known about it, which would be maybe 10 years?
I don't use much of the various SSH/mux features, 'cos I don't use multiple buffers, just multiple tabs.
I like the scrollback and the footer and the integration with the shell, don;t care about scrolling speed very much, and it's sort of the "ain't broke, so why change".
I'll take a look at ghostty, but not sure it gives me much.
As for this security issue, it's a bug, the author found it, fixed it, announced what it was, and how to ameliorate the effects of the issue.
He did that in a very reasonable timeframe and has been entirely open about it.
The pile-on of moralists and what appear to be purists (and possibly early stage devs if they think process is the answer) is sorta pathetic.
This entire thread is more twitter/reddit than what I've come to expect on HN.
I don't use much of the various SSH/mux features, 'cos I don't use multiple buffers, just multiple tabs.
I like the scrollback and the footer and the integration with the shell, don;t care about scrolling speed very much, and it's sort of the "ain't broke, so why change".
I'll take a look at ghostty, but not sure it gives me much.
As for this security issue, it's a bug, the author found it, fixed it, announced what it was, and how to ameliorate the effects of the issue.
He did that in a very reasonable timeframe and has been entirely open about it.
The pile-on of moralists and what appear to be purists (and possibly early stage devs if they think process is the answer) is sorta pathetic.
This entire thread is more twitter/reddit than what I've come to expect on HN.
hah! Clicking "Remind Me Later" for the update prompts works again!
Not sure what the replies here are on about. This is NOT a "whoopsie, can happen to any project" bug. There was code in the project that EXPLICITLY leaked stuff into the remote host. Am I missing something?
Not only would switching to a different project with more eyes on it probably never do this, it would also probably never let that through PR reviews.
Not only would switching to a different project with more eyes on it probably never do this, it would also probably never let that through PR reviews.
Are you offering to review PRs of a different project? That’s actually very beneficial. Which project are you planning to support like this?
Not sure what to make of this snarky ass reply, I do plenty of open source work, not sure why that would be warranted as a reply.
Just because I like open source, doesnt mean I need to do literally all the work.
Just because I like open source, doesnt mean I need to do literally all the work.
Doing open source work, while extremely cool, is off topic when it’s about other open source projects.
If you’re not going to work on a project, trust those who are going to work on it. Or move to a different software I guess.
If you’re not going to work on a project, trust those who are going to work on it. Or move to a different software I guess.
Only when verbose logging is enabled, which seems fine to me
What's not fine is verbose logging being turned on by default, most likely by mistake
What's not fine is verbose logging being turned on by default, most likely by mistake
I always preferred alacritty which is faster and hopefully safer.
Tha macOS part uses the rust `objc2` crates which I find high quality and the codebase is a joy to read.
Tha macOS part uses the rust `objc2` crates which I find high quality and the codebase is a joy to read.
I'm confused by the comments saying "Just don't use iTerm2." The same class of issue can occur for any other project, and switching is not a very effective defense against it.
If anything, having an embarrassing issue like this is probably going to improve the iTerm2 project's security posture in the medium term. It's like that joke about firing the engineer who caused the incident, and the manager who retorts, "Why would I fire them? They just learned the hard way never to make this mistake again." (I'm paraphrasing.) I don't think that iTerm2 has had a notably high rate of critical security issues, and I suspect they won't make this class of mistake twice. (And if they do - then I will re-evaluate.)
I suppose intuitively I would think that using the default MacOS Terminal app is a bit lower-risk than using iTerm2 or any other open source terminal emulator, as Terminal is a rather sparse piece of Apple-provided software with a low pace of change. But it's also closed source and impossible to audit, so there are tradeoffs there too.
If anything, having an embarrassing issue like this is probably going to improve the iTerm2 project's security posture in the medium term. It's like that joke about firing the engineer who caused the incident, and the manager who retorts, "Why would I fire them? They just learned the hard way never to make this mistake again." (I'm paraphrasing.) I don't think that iTerm2 has had a notably high rate of critical security issues, and I suspect they won't make this class of mistake twice. (And if they do - then I will re-evaluate.)
I suppose intuitively I would think that using the default MacOS Terminal app is a bit lower-risk than using iTerm2 or any other open source terminal emulator, as Terminal is a rather sparse piece of Apple-provided software with a low pace of change. But it's also closed source and impossible to audit, so there are tradeoffs there too.
I don't think Apple terminal is sparse at all. Try to dig through the preferences, there's surprisingly much choice for an opinionated software vendor like Apple. I love it, I've tried iTerm2 in the past but I just saw no reason to keep using it. The only feature that slightly appealed to me was the tmux integration but I found that i preferred to just have tmux inside the terminal instead.
I know some people that use the game-like rolldown interface (quake mode?) but I also don't like/need that one. There's a few niche things like that which make it interesting. But overall I just don't see the need.
If there's something that's sparse in options, it's Windows Terminal. Don't like that one at all (though it's better than the previous command prompt window).
I know some people that use the game-like rolldown interface (quake mode?) but I also don't like/need that one. There's a few niche things like that which make it interesting. But overall I just don't see the need.
If there's something that's sparse in options, it's Windows Terminal. Don't like that one at all (though it's better than the previous command prompt window).
Ghostty has the quake mode interface and has allowed me to overcome my shame for never graduating to iTerm. I can't remember much about the game except the giblets but hopefully I've understood.
The majority of configuration options in Windows Terminal are hidden in JSON. The GUI only exposes a fraction. They are doing work to expose more options in the GUI though.
Having tried various alternatives for prolonged periods, it is currently IMHO the best option when you have to work on Windows.
Mac and Linux options are just vastly ahead.
Having tried various alternatives for prolonged periods, it is currently IMHO the best option when you have to work on Windows.
Mac and Linux options are just vastly ahead.
Ah I see. I only used it since the beginning and I hated it and didn't go back. Certainly didn't explore json options :) Thanks!
I really hate working on windows too and our company is tightening stuff down so crazily that I can hardly work anymore so I mostly work on my home lab in Linux and transfer stuff there. Totally not allowed by my employer but they make it impossible for me to work otherwise.
I really hate working on windows too and our company is tightening stuff down so crazily that I can hardly work anymore so I mostly work on my home lab in Linux and transfer stuff there. Totally not allowed by my employer but they make it impossible for me to work otherwise.
I used iTerm2.app for a while, back when Terminal.app didn't support 256 colors. That was literally the only reason and I ditched it the day Terminal.app got 256c, many years ago, now.
It however doesn't have 24bit color still
Which is not an issue for me as 256c is my sweet spot.
Meh that's kinda overrated. There's only so many colours you can discern in individual letters.
Sure, the issue is that it doesn't gracefully degrade when presented with 24bit color.
Tmux does, though!
I used iTerm2 for a while before realising that tmux automatically maps 24-bit colors to 256color. It works well enough for me that I switched back to Terminal.app.
I used iTerm2 for a while before realising that tmux automatically maps 24-bit colors to 256color. It works well enough for me that I switched back to Terminal.app.
Well, assuming 24bit—or anything from a terminal emulator, really—is not a very bright strategy.
Depends on your colour palette :-P.
> I've tried iTerm2 in the past but I just saw no reason to keep using it.
One feature that's cool in iTerm2 is that you can define the left and right margins so using Vim full-screen looks nicer (I hate narrow margins). But I've switched to Sublime text for everything so I stopped using iTerm2.
One feature that's cool in iTerm2 is that you can define the left and right margins so using Vim full-screen looks nicer (I hate narrow margins). But I've switched to Sublime text for everything so I stopped using iTerm2.
I love Terminal. I tried iTerm2 but never got the appeal and switched back to Terminal.
Windows Terminal has a ton of options these days. Last time I used Apple's, it had very US-centric handling of Alt/Option, unlike iTerm2.
I am inclined to say that a low pace of change isn't necessarily a problem for something that at its core emulates 70s hardware.
It can easily become a problem if you don't leave it at that and add everything and the kitchen sink to it. Not having used the feature I have a hard time imagining why a terminal emulator should have SSH integration to begin with.
It can easily become a problem if you don't leave it at that and add everything and the kitchen sink to it. Not having used the feature I have a hard time imagining why a terminal emulator should have SSH integration to begin with.
Hardware in the 70s was full of security issues. Designing a secure terminal emulator is actually quite difficult.
> Hardware in the 70s was full of security issues.
It's however clearly not in the "70s hardware portion" of iTerm that this issue arises. Also not in the features we've come to expect of the most bare bones terminal emulators since, like Unicode support, scrollback buffers and font rendering, or even the somewhat gratuitous features like escape sequences for RGB colors, setting the window title or sixel rendering.
This is very clearly one of the kitchen sink features, and playing the devil's advocate I should say that it reflects poorly on the kitchen sink design ethos.
It's however clearly not in the "70s hardware portion" of iTerm that this issue arises. Also not in the features we've come to expect of the most bare bones terminal emulators since, like Unicode support, scrollback buffers and font rendering, or even the somewhat gratuitous features like escape sequences for RGB colors, setting the window title or sixel rendering.
This is very clearly one of the kitchen sink features, and playing the devil's advocate I should say that it reflects poorly on the kitchen sink design ethos.
The comment puts the slow pace of change as an advantage. Pretty standard security principle.
Ssh integration brings lots of other "local" iterm features based on command history, etc. to the ssh environment. If you do lots of ssh work and use a lot of relevant iterm features then it's nice. Otherwise not.
Obviously, these features can be recreated with traditional tools. But these tools take time and experience to setup, and aren't naturally intuitive, despite the insistence of emacs elitists. For those who don't want to invest significant effort learning tmux, it's really nice to just check/uncheck a few boxes.
Ssh integration brings lots of other "local" iterm features based on command history, etc. to the ssh environment. If you do lots of ssh work and use a lot of relevant iterm features then it's nice. Otherwise not.
Obviously, these features can be recreated with traditional tools. But these tools take time and experience to setup, and aren't naturally intuitive, despite the insistence of emacs elitists. For those who don't want to invest significant effort learning tmux, it's really nice to just check/uncheck a few boxes.
The built-in Terminal is a) simpler, smaller attack surface b) older c) supported by probably more than one person, in a more risk-averse org d) used by a lot more people so issues will get noticed and fixed sooner e) part of a pretty robust public beta OS program.
Just don't use iTerm2.
Just don't use iTerm2.
Point D is a thing we assume about software but over time you realize it's not the case. You'll see a native macOS app like Terminal and assume it's blessed by Apple, has its own dedicated team with daily standup and meetings, but it's actually just propped up by random tickets in a larger issue tracker, doesn't have a dedicated team, and depends on what amounts to begrudged work or charity work by whoever happens to work on a ticket in passing.
A random rockstar will come in and move the code forward 5 years never to be seen again.
A random rockstar will come in and move the code forward 5 years never to be seen again.
And best of all, not as good, and not open source!
Windows Terminal is though!
I really dislike that one. Not enough configurability. Unlike Apple terminal which is kinda surprising because normally Microsoft is the one with all the option settings and Apple makes the opinionated software where they decide everything and the user has to take it as it comes.
But Microsoft is becoming similar unfortunately. You can see it in other software too, like them discontinuing the real Outlook and replacing it with a web one that has much fewer options, can't even be started up offline (!) and wastes more screen space. And they are moving more and more apps to electron or their own knockoff of it.
But Microsoft is becoming similar unfortunately. You can see it in other software too, like them discontinuing the real Outlook and replacing it with a web one that has much fewer options, can't even be started up offline (!) and wastes more screen space. And they are moving more and more apps to electron or their own knockoff of it.
Windows terminal is great. Very performant and looks really nice. I also have mobaxterm for doing work remote machines, but for local work using WSL Ubuntu it’s my preferred terminal by far.
How do you judge performance of a terminal ? I know graphics in the terminal is an edge case and all but when I'm running a chafa [0] application Windows terminal on Windows is about 1000x slower than alacritty on mac, I run into issues where if I hold down a key all the key events get queued up as if the graphics thread is blocking the applications ability to react to key events, so I just have to baby it and hit one key at a time.
[0] https://hpjansson.org/chafa/
[0] https://hpjansson.org/chafa/
Oh I used it only when it first came out. I went back to PuTTY (i never use the console on windows for other stuff and I'm not allowed to use WSL at work). And at home i only have a windows box for gaming.
So there was some assumption on my part sorry. But informed assumption because other stuff I work with (Teams, Outlook) have only become much worse since their release :)
So there was some assumption on my part sorry. But informed assumption because other stuff I work with (Teams, Outlook) have only become much worse since their release :)
To be a fly on the wall when they decide to go live with a Teams (New) that asks if you want to keep using Teams [not new].
Open source — monkey's paw curls — but spies on you https://github.com/search?q=repo%3Amicrosoft%2Fterminal+tele...
That’s anything Microsoft makes these days.
we're talking about Mac terminals.
You forgot f) so lacking in features that it's a productivity roadblock
What missing features do you see as a roadblock?
I installed iTerm2 on my work Mac because it came so highly recommended, but I honestly never remember to open it over the regular terminal. ~All of the features that matter to me in a terminal are features of the shell and the OS, not of the emulator itself.
I installed iTerm2 on my work Mac because it came so highly recommended, but I honestly never remember to open it over the regular terminal. ~All of the features that matter to me in a terminal are features of the shell and the OS, not of the emulator itself.
Iterm is better documented. Try finding how to pass Ctrl-Meta-key; better yet, throw in a shift as well. Setting up 24bit color, supporting italics, and allowing Emacs keystrokes to go through to the remote server at will is a quality of life improvement. I managed to be feature complete with iterm on macOS with minimal effort, but not with the default terminal, and there was no source code I could check to help me avoid trivial annoyances. Xterm/rxvt from xQuartz on Mac OS are easier to work with than the default Mac OS terminal, and feel closer to their behavior in Linux, but then you have some unneeded X window features and miss other trivial automation features like multiple tabs.
iTerm2 is slower. It feels way jankier with nvim than Console, kitty or literally anything else.
I do not believe anyone should be using iterm2, given their history of security issues. All of them leave me scratching my head as to why did anyone think that designing it the way they did is a good idea.
The idea that iTerm is noticeably slow is hilarious.
If you buy a base model grandma level MacBook Air it can play Cyberpunk 2077 without breaking a sweat and somehow terminal performance is an issue.
And if all I cared about was raw performance I’d be using vim instead of VSCode. But raw performance isn’t what makes me productive.
If you buy a base model grandma level MacBook Air it can play Cyberpunk 2077 without breaking a sweat and somehow terminal performance is an issue.
And if all I cared about was raw performance I’d be using vim instead of VSCode. But raw performance isn’t what makes me productive.
But it is. Scrolling in neovim is noticably slower on iTerm2. This makes it cumbersome to use. Even if it doesn't prevent me from inputting the keystrokes any faster, if it is cumbersome to use, it will make me work slower.
I've used numerous terminal emulators on both macOS and Linux. I use Neovim daily. There is no noticeable difference in scrolling performance.
Additionally, there are so many ways scrolling can slow down in Neovim (e.g., bad tmux config). It's hard to take your word for it that the issue lies in iTerm2 in the absence of any sort of reproducible evidence.
Additionally, there are so many ways scrolling can slow down in Neovim (e.g., bad tmux config). It's hard to take your word for it that the issue lies in iTerm2 in the absence of any sort of reproducible evidence.
There might be some tmux involved, yes. But the same tmux config works just fine with Kitty. Kitty also hasn't been leaking commands I've ran as DNS requests. Nor has it left my zsh history on a remote host. I don't care to investigate why iTerm2 works worse for me because I am satisfied enough with a solution that works. iTerm2 not working for me rhymes with my previous experiences with iTerm2 and its security issues.
That's uncalled for. Security issues are quickly fixed and released in iTerm2. The dev is responsive to feedback, even to hostile Mastodon trolls brigading the issue tracker [1].
Please don't be like that.
Also, any serious software has its own share of problems. Have you actually looked at the issue tracker for your supposed champion?
[1]: https://news.ycombinator.com/item?id=40657890
Please don't be like that.
Also, any serious software has its own share of problems. Have you actually looked at the issue tracker for your supposed champion?
[1]: https://news.ycombinator.com/item?id=40657890
What specifically is uncalled for? I disagree with the design choices made in iTerm2 and wish the best of luck to the developer(s) behind it. I am not wishing any harm, but I do have to say that the input latency is annoying and attempting to resolve words in command output to see if they are hostnames is a dubious technical solution. Am I not allowed to voice my opinion on this?
People are allowed to have preferences and dislike software.
Similarly, if your mechanic forgets to tighten the lug nuts or leaves the oil cap off, and nearly kills you or destroys the engine, you are allowed to find a new mechanic without the Hackernews hoi polloi coming out of the woodwork saying how unfair it is, he has mouths to feed, and linking to critical Yelp reviews of your new mechanic trying to convince you of your own idiocy and wrongdoing.
This emotional attachment to a piece of throwaway software here is frankly weird.
Similarly, if your mechanic forgets to tighten the lug nuts or leaves the oil cap off, and nearly kills you or destroys the engine, you are allowed to find a new mechanic without the Hackernews hoi polloi coming out of the woodwork saying how unfair it is, he has mouths to feed, and linking to critical Yelp reviews of your new mechanic trying to convince you of your own idiocy and wrongdoing.
This emotional attachment to a piece of throwaway software here is frankly weird.
An entire thread of neovim users generally saying that the performance is acceptable: https://www.reddit.com/r/neovim/s/JOQL9e76fp
Just because something else is faster doesn’t mean that iTerm is slow. It’s all relative.
Just because something else is faster doesn’t mean that iTerm is slow. It’s all relative.
Cyberpunk 2077 on a MacBook Air without breaking a sweat? At what resolution and framerate?
The plain M4 chip will run Cyberpunk 2077 at 30FPS 1080p. (Andrew Tsai on YouTube)
I did neglect the fact that Apple hasn’t thrown that chip in the Air yet, but I’m sure that’s only a few months away.
I did neglect the fact that Apple hasn’t thrown that chip in the Air yet, but I’m sure that’s only a few months away.
At ultra settings? Even if, 30 fps at 1080p is not nearly “without breaking a sweat”. Also, the air will have trouble keeping that performance after a few minutes without a fan.
I love my MBP M4 Pro, but its gaming performance doesn’t reflect well what it’s capable of.
I love my MBP M4 Pro, but its gaming performance doesn’t reflect well what it’s capable of.
This is at High settings! And I haven’t even mentioned that the game is running via Crossover through multiple translation systems. That’s translating both Intel Windows to ARM Mac as well as translating the graphics APIs (DirectX or Vulkan to Metal).
The cyberpunk native Mac release comes out this year and will almost certainly improve performance further.
Why would anyone care about ultra settings on a laptop? I don’t even set my PC desktop to ultra settings in the game and I have a current generation mid-high end GPU. Setting demanding games to Ultra just giving up FPS to not tell the difference.
30fps 1080p is basically console-level standards for a AAA graphically intense game (not esports or online shooter). And that isn’t bad at all for the processor with integrated graphics that Apple sticks in its cheapest computer and its tablets.
Your MacBook Pro M4 Pro is one of the best gaming laptops on the market in terms of hardware! Especially if you want something that’s thin, light, and quiet with good battery life and not just a thick tank of a system or a loud but thin and light gaming laptop that struggles to power and cool its dGPU.
Depending on your configuration, you can actually play Cyberpunk at high settings at or above 60FPS on your laptop. You’re vastly underestimating it!
Your laptop just needs the software to get ported, and the Mac gaming space is rapidly evolving now that Apple is paying attention to it.
The cyberpunk native Mac release comes out this year and will almost certainly improve performance further.
Why would anyone care about ultra settings on a laptop? I don’t even set my PC desktop to ultra settings in the game and I have a current generation mid-high end GPU. Setting demanding games to Ultra just giving up FPS to not tell the difference.
30fps 1080p is basically console-level standards for a AAA graphically intense game (not esports or online shooter). And that isn’t bad at all for the processor with integrated graphics that Apple sticks in its cheapest computer and its tablets.
Your MacBook Pro M4 Pro is one of the best gaming laptops on the market in terms of hardware! Especially if you want something that’s thin, light, and quiet with good battery life and not just a thick tank of a system or a loud but thin and light gaming laptop that struggles to power and cool its dGPU.
Depending on your configuration, you can actually play Cyberpunk at high settings at or above 60FPS on your laptop. You’re vastly underestimating it!
Your laptop just needs the software to get ported, and the Mac gaming space is rapidly evolving now that Apple is paying attention to it.
Latency during typing is a real issue, not sure what you find hilarious here.
I wanted to like kitty and tried it many times. It is subtle issues that break Emacs now and then, like breaking the display alignment for some zero-width joined emoji. Iterm2 on a MacBook is snappy for me. With remote work, the latency for me is mostly network delays of order a couple of ms per keystroke for the cabled Ethernet connection; mosh helps for the extreme cases, or when on WiFi (which often feels annoying without mosh), otherwise ssh -C is sufficient for my daily driver.
I don’t know about the rest, but I’m sure Terminal supports italic.
Quake mode. Terminal doesn't have it, and the recently released Ghostty's quake mode is slower than iTerm2.
There's very little I want in a terminal emulator. What I really want is a full screen terminal, with no menu bar, no delay, and no animations, which I can toggle with a global hotkey.
There's very little I want in a terminal emulator. What I really want is a full screen terminal, with no menu bar, no delay, and no animations, which I can toggle with a global hotkey.
It strikes me as a little odd for the terminal rather than the desktop environment within which it runs to implement the hotkey (or, as you call it, ‘Quake mode’).
I just have my tiling window manager configured with a keybinding to raise my terminal. No menu bar, no delay, no animation, just type the keybinding and bam, there’s my console, covering the complete screen. Another keybinding, and there’s my browser. Another keybinding, and there’s my editor.
I just have my tiling window manager configured with a keybinding to raise my terminal. No menu bar, no delay, no animation, just type the keybinding and bam, there’s my console, covering the complete screen. Another keybinding, and there’s my browser. Another keybinding, and there’s my editor.
How are you achieving this in MacOS?
> How are you achieving this in MacOS?
I don’t — I use Linux on my desktop. I stopped using macOS back when it was called System 8 or 9!
I think any tiling window manager can be configured to do this, but in my case I use StumpWM.
From others’ comments, I think that this is probably possible with a modern Mac, too, but I find that Linux is generally easier.
StumpWM: https://stumpwm.github.io/
I don’t — I use Linux on my desktop. I stopped using macOS back when it was called System 8 or 9!
I think any tiling window manager can be configured to do this, but in my case I use StumpWM.
(defcommand terminal () ()
(run-or-raise "urxvt" '(:instance "urxvt")))
(define-key *top-map* (kbd "s-t") "terminal")
From others’ comments, I think that this is probably possible with a modern Mac, too, but I find that Linux is generally easier.
StumpWM: https://stumpwm.github.io/
That sounds great, but I'm not changing my entire operating system just so I can have a possibly marginally better terminal emulation experience.
You would also get a better window manager, better compatibility with server operating systems, a bash updated this decade, XCompose (think the Option key, but way, way, way more powerful) and more freedom, but on the other hand you’d lose macOS-only programs, and from time to time would have to deal with something truly frustrating which would never be an issue on a Mac.
It’s certainly not perfect, but I do prefer it. But then, I enjoy yak shaving grin
It’s certainly not perfect, but I do prefer it. But then, I enjoy yak shaving grin
> I enjoy yak shaving
As my username would suggest, so do I. However…
> a better window manager
The bulk of my workflow involves Chrome and tmux inside my always available full screen terminal. I haven't the need for multiplexing anywhere except the terminal.
> better compatibility with server operating systems
I run nix-darwin on MacOS, and I have remote NixOS machines configured as build hosts. This is important, as everything I write is Haskell, and it must be compiled for x86_64-linux.
> a bash updated this decade
I use zsh and the bash available in the latest nixpkgs.
---
MacOS does an excellent job of managing all the other quality of life stuff that doesn't immediately concern me as a power user. A number of my current and former colleagues are all in on NixOS, but the number of times over the years I've had to wait at the beginning of a video chat for them to configure their audio settings, which sometimes means installing different drivers and/or turning their machine off and on again…
Yeah. Even as a huge nerd, I think MacOS is great.
As my username would suggest, so do I. However…
> a better window manager
The bulk of my workflow involves Chrome and tmux inside my always available full screen terminal. I haven't the need for multiplexing anywhere except the terminal.
> better compatibility with server operating systems
I run nix-darwin on MacOS, and I have remote NixOS machines configured as build hosts. This is important, as everything I write is Haskell, and it must be compiled for x86_64-linux.
> a bash updated this decade
I use zsh and the bash available in the latest nixpkgs.
---
MacOS does an excellent job of managing all the other quality of life stuff that doesn't immediately concern me as a power user. A number of my current and former colleagues are all in on NixOS, but the number of times over the years I've had to wait at the beginning of a video chat for them to configure their audio settings, which sometimes means installing different drivers and/or turning their machine off and on again…
Yeah. Even as a huge nerd, I think MacOS is great.
I do this using Raycast, no matter which terminal emulator I'm using today (Terminal, Ghostty or Alacritty), I can just setup my global hotkey in Raycast and get the same "quake mode" everywhere.
Does the terminal appear instantly, and obscure everything else?
By default, the way MacOS does full-screen windows is by moving them to a space. Switching between the terminal and another application, e.g., Chrome, causes a large sliding animation between applications, which I absolutely do not want.
By default, the way MacOS does full-screen windows is by moving them to a space. Switching between the terminal and another application, e.g., Chrome, causes a large sliding animation between applications, which I absolutely do not want.
Oh I don't have it fullscreen, sorry, it usually covers the bottom half or bottom-left corner (depending on screen size). There it appears and disappears instantly.
Another option is rcmd. https://lowtechguys.com/rcmd/
I do something similar and I use Hammerspoon (with kitty in my case). It’s a hell of a tool!
I have never felt a productivity roadblock from terminal. It’s important to distinguish “oh neat and shiny”/“I like this more” from “actually makes me work faster”. If your terminal is a real productivity roadblock, it’s likely your workflow is optimizing for the wrong things because it just shouldn’t be taking that much of your time.
I work on a laptop with a small scren most of the time. I am constantly going in and out of the shell. iTerm2 has a quake mode that allows me to seamlessly pull this up on top with a keypress. It significantly reduces the lag of switching to another window with CMD+Tab or w/e.
Some of this stems from just the extremely bad support for hotkey window management on the part of MacOS.
On my Linux machine with KDE I can open a new terminal with a single hotkey and alternate between open terminals with a second hotkey. I've never once wished for a fancier terminal than KDE's default.
Using Mac for work is a different story, though it's remedied somewhat with Rectangle and similar.
On my Linux machine with KDE I can open a new terminal with a single hotkey and alternate between open terminals with a second hotkey. I've never once wished for a fancier terminal than KDE's default.
Using Mac for work is a different story, though it's remedied somewhat with Rectangle and similar.
[deleted]
The small screen is your productivity bottleneck far more than the terminal itself. Change that and I’m sure you’ll notice a much larger productivity boost than a few seconds saved on cmd-tab or other hotkeys available (and there are hotkey improvement tools you can install that aren’t tied to a specific application).
I move around a lot and travel light, upgrading the small screen isn't really an option. I definitely agree there are probably countless ways I could further optimize my system, but switching to a more feature-rich shell app is a clear productivity upgrade, since it only took me a few minutes to setup the features I need (security concerns aside).
Bringing a mobile external monitor with me saved my life (figuratively).
ghostty has a quick terminal too. you can also use raycast to toggle show/hide any app including third party terminals.
Neovim is basically unusable due to the plugins I use having Unicode characters not supported properly (like telescope), so it does make a huge difference to me. Also, latency is an issue, and of the third-party terminals, only kitty is snappy enough to have nearly zero latency issues while typing. Drives me crazy when I’m chaining commands and there is a ~150ms delay.
Plus, any terminal other than kitty is noticeably laggy when using other terminal programs and typing quickly, and 90%+ of my time is spent in the terminal: using custom commands and aliases, ruby shell, docker, on top of usually using vim for editing. And having great customizable hotkeys for different common functions.
Guess my point is that the terminal app you use can make a big productivity difference
Plus, any terminal other than kitty is noticeably laggy when using other terminal programs and typing quickly, and 90%+ of my time is spent in the terminal: using custom commands and aliases, ruby shell, docker, on top of usually using vim for editing. And having great customizable hotkeys for different common functions.
Guess my point is that the terminal app you use can make a big productivity difference
You're right, all those users that switched to iterm2 because the default is such a steamer have NO IDEA what they are doing, and only you, some random on the internet are capable of seeing the flaw in their ways.
People can switch because certain things feel easier or there’s nicer polish or quality of life improvements you enjoy. That doesn’t mean there’s an actual productivity boost and couching the former in terms of the latter is dishonest.
It’s interesting the emotional reaction you’re having to a rather banal observation.
It’s interesting the emotional reaction you’re having to a rather banal observation.
are you mental? terminal on os x used to be objectively shite, with horrendous latency. that is enough to discourage people for life.
As old UNIX hat, what is that missing?
After my "UNIX is cool, lets configure everything" phase, which lags behind in the 1990's decade, xterm or anything like it, is more than enough.
I don't need fancy stuff for a bunch of CLI commands.
After my "UNIX is cool, lets configure everything" phase, which lags behind in the 1990's decade, xterm or anything like it, is more than enough.
I don't need fancy stuff for a bunch of CLI commands.
This is macOS, not UNIX for bearded geezers. It’s literally an operating system meant to be easy to use for consumers, a.k.a. morons.
It’s also a very popular corporate deployments where most of your command line users are web application developers who are just doing a job because it pays good money. They have no philosophical attachment to traditionalist simplicity, perhaps compassion nonfor computing at all.
I don’t blame macOS users for liking the features of iTerm2.
It’s also a very popular corporate deployments where most of your command line users are web application developers who are just doing a job because it pays good money. They have no philosophical attachment to traditionalist simplicity, perhaps compassion nonfor computing at all.
I don’t blame macOS users for liking the features of iTerm2.
> consumers, a.k.a. morons.
Wtf man. Some of the smartest people I know have no interest in getting anywhere close to sw eng or working anywhere in IT, so are by definition "consumers".
Just wait until one of those "morons" operates a tumor out of your brain.
Wtf man. Some of the smartest people I know have no interest in getting anywhere close to sw eng or working anywhere in IT, so are by definition "consumers".
Just wait until one of those "morons" operates a tumor out of your brain.
[deleted]
I've always said that "consumer" is a slur.
It's just humor. I'm a moron myself. It's not a big deal.
The more serious point is that Apple's primary customer base does not care for what's going on with the command line, and that's why the provided terminal is basic and feature-bare.
It's not really this intentional thing where the bare terminal is the best implementation. It's more of a Notepad.exe situation where Apple has to include one for the basic functionality of the system.
The more serious point is that Apple's primary customer base does not care for what's going on with the command line, and that's why the provided terminal is basic and feature-bare.
It's not really this intentional thing where the bare terminal is the best implementation. It's more of a Notepad.exe situation where Apple has to include one for the basic functionality of the system.
Which is exactly why the command line is to be used as little as possible, and for the very few use cases a command line is required, it doesn't need to be fancy.
macOS users of Apple and NeXTSTEP culture linage don't care iTerm2 exists at all, only Linux and BSD refugees.
macOS users of Apple and NeXTSTEP culture linage don't care iTerm2 exists at all, only Linux and BSD refugees.
As an original Macintosh user who discovered programming via HyperCard and Unix through OS X I’d disagree. I think there are a fair number of people like me who can’t bear the ugliness (in all senses) of windows and the time sink of Linux but do love composable open source utilities and text files for parts of our work.
Then you are pretty much aware that until OS X, Mac OS developers and users hardly cared about command line.
Most would only get it via MPW, and outside automating compiler workflows, hardly open the terminal.
Most would only get it via MPW, and outside automating compiler workflows, hardly open the terminal.
That was almost 30 years ago.
People on classic Mac weren’t making web apps running on Linux servers.
People on classic Mac weren’t making web apps running on Linux servers.
Doesn't change the point of culture.
Also many of those people, if they want to deploy on Linux servers, they would be better off using local Linux development, not OS X.
Also many of those people, if they want to deploy on Linux servers, they would be better off using local Linux development, not OS X.
Even if someone exclusively writes software that ends up running on Linux servers, doesn't mean they don't appreciate various nice Mac-exclusive applications as a user during their workday.
An example: I love everything about the Things task management app so much that I would never choose to run a desktop OS it doesn't run on.
An example: I love everything about the Things task management app so much that I would never choose to run a desktop OS it doesn't run on.
I wonder how far this reductio ad absurdum is going to get. Come on, we can get to "just don't use a computer" by teatime!
Over here it is more like Kaffee & Kuchen, but yeah.
That’s completely untrue.
winaiisbest(1)
I don’t have the stats, but I wouldn’t be surprised if iterm 2 is more popular than Terminal.app. Only power users are using this, and they tend towards power user tools.
> Only power users are using this, and they tend towards power user tools.
I have a souped-up zsh config that I clone to all my systems, but I've honestly never seen the point in optimizing my terminal emulator. The shell itself provides the real functionality, and it's cross-platform so by leaning on it I get the same features whether I'm on my KDE desktop, MacBook, or SSH'd in via Termux.
What power user features am I missing by ignoring the emulator and focusing on the shell?
I have a souped-up zsh config that I clone to all my systems, but I've honestly never seen the point in optimizing my terminal emulator. The shell itself provides the real functionality, and it's cross-platform so by leaning on it I get the same features whether I'm on my KDE desktop, MacBook, or SSH'd in via Termux.
What power user features am I missing by ignoring the emulator and focusing on the shell?
There's some minor things that iTerm2 does that I like:
You can hold down command and click URLs to open them. (You can actually kinda do this in Terminal.app as well by right-clicking a URL and choosing to open it, but it's a bit fiddlier, and I got used to the hover feedback in iTerm2.)
You can click to highlight entire blocks of output from commands, which I sometimes find handy when things feel like they're blending together.
It'll keep a floating copy of the previous command prompt at the top of the screen so you can see what led to whatever output is currently at the top.
None of these are essential, for sure.
You can hold down command and click URLs to open them. (You can actually kinda do this in Terminal.app as well by right-clicking a URL and choosing to open it, but it's a bit fiddlier, and I got used to the hover feedback in iTerm2.)
You can click to highlight entire blocks of output from commands, which I sometimes find handy when things feel like they're blending together.
It'll keep a floating copy of the previous command prompt at the top of the screen so you can see what led to whatever output is currently at the top.
None of these are essential, for sure.
Though I don't know how to do the third, Terminal.app supports the first two. Command+double-click opens URLs, and you can select the content of the last command with Edit > Select Between Marks or shift-command-A. (Terminal.app automatically adds a mark each time it detects a new prompt, unless you turn that setting off in Edit > Marks.)
This is actually one of those cases where the ease of doing it makes a real difference to me… iTerm2 does both of those on a single click, and that makes it vastly more likely that I’ll use them. (Completely a matter of taste, I’ll admit.)
Being able to easily set it up so it sends key combinations to remote servers at will (including ctrl/meta/shift combos) was my main reason; this enabled my seamless interactions with remote Emacs servers. 24bit color and italics were the cherry on top. The shells within Emacs have unlimited and easily searchable/editable state. I can log into a shell buffer and copy paste a debug diagnostic output together with the command line; I can quickly create minimal example oneliners iteratively to help debug a problem and paste both input and output at any point in time, including days later. I can search all my open shells (often dozens; sometimes hundreds) for any commands or outputs trivially. This is hard to achieve if the terminal gets in the way to using Emacs in the way I like, when some key combo is impossible to transmit, and I have to rewire things to the minimal common subset that Terminal.app supports and hope that it will not break in the future. Finally, without public source code, I dont think I can truly trust a terminal ever. It feels too personal. Of course apple has control of the hardware and I live with that restriction for parts of my life, but I am less concerned about apple monitoring/intercepting my work, and rather worried about the full number of exploits in the terminal app that remain to be uncovered in the near term. I agree that too many features are a drawback of iterm; at least the code is there and the useful features work well enough.
I no longer use iTerm2 but it has tmux integration built in that's pretty nice if you take the time to set it up properly.
I tried that but I feel the same about that as lolinder says above. Using tmux as normal works better on all my systems, not just the Mac. I just don't see the point to it.
If by “popular” you mean “number of unique users” then almost certainly not.
There are way more power users of macOS who turn to the Terminal because of the beauty of Brew than there are people who switch from Terminal.app.
Thinking there are more people who switched out of Terminal diminishes how massive computing is.
Thinking there are more people who switched out of Terminal diminishes how massive computing is.
It also doesn't render unicode characters correctly (specifically unicode block chars). And they refuse to fix is, so d. is kinda a moot point.
It’s fine if you don’t want features in your terminal, but telling people who do like having software that has features not to use an alternative just because “more features equals complexity equals security risk” in the way you’re doing it is pretty condescending.
Let’s not forget that basically every graphical IDE on the planet has an integrated terminal emulator, and for good reason
I’d have a smaller attack surface if I turned my computer off and did all my work for my employer with pen and paper. I’d have a smaller attack surface if I didn’t buy a Mac at all and only used a security-hardened distro.
And here you are acting like Apple is God’s gift to stability and security when every single fall season Apple’s major dot zero version updates ship with visible bugs all over the place.
And to nitpick you, the assumption that more than one person is actively working on the default macOS terminal is laughable. I doubt it even has a full time employee dedicating 100% of their time to it. The yearly release notes look like less than one person’s annual output of work.
I remember that thread on here where the person who worked on Rosetta 2 said it was a solo project for years until closer to release when the team expanded to around 10.
Let’s not forget that basically every graphical IDE on the planet has an integrated terminal emulator, and for good reason
I’d have a smaller attack surface if I turned my computer off and did all my work for my employer with pen and paper. I’d have a smaller attack surface if I didn’t buy a Mac at all and only used a security-hardened distro.
And here you are acting like Apple is God’s gift to stability and security when every single fall season Apple’s major dot zero version updates ship with visible bugs all over the place.
And to nitpick you, the assumption that more than one person is actively working on the default macOS terminal is laughable. I doubt it even has a full time employee dedicating 100% of their time to it. The yearly release notes look like less than one person’s annual output of work.
I remember that thread on here where the person who worked on Rosetta 2 said it was a solo project for years until closer to release when the team expanded to around 10.
> Let’s not forget that basically every graphical IDE on the planet has an integrated terminal emulator, and for good reason
*cries in Xcode
*cries in Xcode
You forgot f) doesn't support tmux control mode.
> having an embarrassing issue like this is probably going to improve
LastPass disagrees.
LastPass disagrees.
> The same class of issue can occur for any other project
DON'T WRITE TO /tmp
https://salvatoresecurity.com/the-many-perils-of-tmp/
https://systemd.io/TEMPORARY_DIRECTORIES/
Safely writing to /tmp/ was solved in 1986. Personally I would consider this class of bug the "idiot software developer" class (or to be more charitable: "security-illiterate software developer"). My evidence? There are (at least) six different OS primitives that will avoid this bug.
> Safely writing to /tmp/ was solved in 1986
> This file, /tmp/framer.txt, may be readable by other users on the remote host.
Yes, there are safe ways to write to /tmp, as described in the systemd link I provided, but no, it is not safe to naively write to /tmp. Same issue as the "Many Perils of /tmp" link I provided.
A solution that no one uses is not a solution.
If you're gonna be arrogant, you better also be right.
What do you mean by saying that the same class of issue can happen to any other terminal emulator?
Unfortunately the isn't the first very serious security oversight with iterm2.
https://news.ycombinator.com/item?id=15286956
https://news.ycombinator.com/item?id=15286956
Honestly that 7 year old thread makes me glad I use iterm2. George posted a fix in a short period of time (which he still does today), and added comments to that thread addressing the issues. Sounds like a decent person who cares about his users.
> George posted a fix in a short period of time
No, the issue had been reported on their bug tracker twice (and closed twice) in the two years prior to their response in the thread. It took a loud enough crowd to convince them it was an issue, even though the original reports described the security implications.
https://gitlab.com/gnachman/iterm2/-/issues/3688 and then https://gitlab.com/gnachman/iterm2/-/issues/5303
Still,
> Sounds like a decent person who cares about his users.
Agreed!
No, the issue had been reported on their bug tracker twice (and closed twice) in the two years prior to their response in the thread. It took a loud enough crowd to convince them it was an issue, even though the original reports described the security implications.
https://gitlab.com/gnachman/iterm2/-/issues/3688 and then https://gitlab.com/gnachman/iterm2/-/issues/5303
Still,
> Sounds like a decent person who cares about his users.
Agreed!
Only if they actually communicate what they’ve learned from it and what changes they’re making to prevent such mistakes in the future / catch them before release. Until then you can assume that they’ll keep making similar classes of mistakes.
What did George ever do to you that warrants this level of contempt and condescension? Am I missing something, because there are so many activists like you having an inexplicable vendetta against iTerm2 all over this thread.
This is sad because iTerm2 is one of the best terminal emulators out there. It's the first terminal emulator that popularized shell integration. Newer terminal emulators are still catching up, a decade later. tmux integration is another popular feature that's still unique to iTerm2. George has been working tirelessly on iTerm2 pretty much solo for 15 years [1]. To this day, he continuously brings new improvements to the terminal experience that keeps being copied by other terminal emulators. Developers benefit from his work, iTerm2 users and non-users alike. We should be expressing our gratitude instead of doing whatever people are doing in this thread.
George found this security issue the day after New Year's day and immediately released a fix [2]. That's commitment. And while the effects of this bug can be severe, most people wouldn't have triggered the bug.
[1]: https://github.com/gnachman/iTerm2/graphs/contributors
[2]: https://github.com/gnachman/iTerm2/commits/master/?since=202...
[3]: https://web.archive.org/web/20240613170001/https://archive.i...
This is sad because iTerm2 is one of the best terminal emulators out there. It's the first terminal emulator that popularized shell integration. Newer terminal emulators are still catching up, a decade later. tmux integration is another popular feature that's still unique to iTerm2. George has been working tirelessly on iTerm2 pretty much solo for 15 years [1]. To this day, he continuously brings new improvements to the terminal experience that keeps being copied by other terminal emulators. Developers benefit from his work, iTerm2 users and non-users alike. We should be expressing our gratitude instead of doing whatever people are doing in this thread.
George found this security issue the day after New Year's day and immediately released a fix [2]. That's commitment. And while the effects of this bug can be severe, most people wouldn't have triggered the bug.
> 1. Either:
> a) You used the it2ssh command, or
> b) In Settings > Profiles > General, the
> Command popup menu was set to "SSH" (not
> "Login Shell", "Command", or "Custom
> Command") AND "SSH Integration" was checked
> in the SSH configuration dialog. That dialog
> is shown when you click the Configure button
> next to the ssh arguments field in Settings.
[1]: https://github.com/gnachman/iTerm2/graphs/contributors
[2]: https://github.com/gnachman/iTerm2/commits/master/?since=202...
[3]: https://web.archive.org/web/20240613170001/https://archive.i...
It's insane and horribly disrespectful. I don't understand the animus either. I just sent a $ donation to the maintainer.
The response to this bug is completely over the top. He found a security issue in an optional feature, immediately fixed it over the New Year holiday, and provided clear documentation about who was affected and how to address it. That's exactly how responsible disclosure should work.
The level of hostility - especially over adding optional features that people can simply choose not to use - suggests this is more about bandwagoning than legitimate criticism. We should be supporting developers who maintain critical open source infrastructure, not attacking them over a prompt response to a contained issue.
The response to this bug is completely over the top. He found a security issue in an optional feature, immediately fixed it over the New Year holiday, and provided clear documentation about who was affected and how to address it. That's exactly how responsible disclosure should work.
The level of hostility - especially over adding optional features that people can simply choose not to use - suggests this is more about bandwagoning than legitimate criticism. We should be supporting developers who maintain critical open source infrastructure, not attacking them over a prompt response to a contained issue.
Donating in times of stress is a great idea, just donated as well.
There is absolutely 0 condescension in my comment. All I highlighted is the flaw in the argument that a mistake made is a lesson learned. Indeed, there’s no indication the root cause of the lesson leading to this situation has indeed been learned.
You seem to be triggered by a perceived critical comment of a piece of software you’ve developed an emotional attachment to. I have not attacked anyone associated with the iterm2 project nor have I questioned his talent in creating a popular project or his commitment to it. Lumping me in with toxic people you encountered on social networks is completely uncalled for and I’ve never called for violence against anyone.
You seem to be triggered by a perceived critical comment of a piece of software you’ve developed an emotional attachment to. I have not attacked anyone associated with the iterm2 project nor have I questioned his talent in creating a popular project or his commitment to it. Lumping me in with toxic people you encountered on social networks is completely uncalled for and I’ve never called for violence against anyone.
You asserted that author hasn't "learned" anything from this bug in a drive-by comment that starts with "Only if they actually ~". I can assure you that's incredibly condescending.
It's uncalled for too. iTerm2 has a good track record responding to user issues, even obscure ones involving Japanese input. The dev even listened to the demands of trolls who raided the issue tracker from Mastodon [1]. Security fixes are released quickly. Nothing about the project warrants the kind of cheap dismissal in display all over this thread.
You mentioned emotional attachment twice in this thread as reason some people have problems with dismissive, aggressive, or mean comments against iTerm2. No, it's basic empathy and appreciation for the thankless work going into this FOSS project.
[1]: https://news.ycombinator.com/item?id=40657890
It's uncalled for too. iTerm2 has a good track record responding to user issues, even obscure ones involving Japanese input. The dev even listened to the demands of trolls who raided the issue tracker from Mastodon [1]. Security fixes are released quickly. Nothing about the project warrants the kind of cheap dismissal in display all over this thread.
You mentioned emotional attachment twice in this thread as reason some people have problems with dismissive, aggressive, or mean comments against iTerm2. No, it's basic empathy and appreciation for the thankless work going into this FOSS project.
[1]: https://news.ycombinator.com/item?id=40657890
No it’s not condescending to highlight the author hasn’t indicated they have learned from the broader set of circumstances that led to this bug in the first place. Ripping out a feature is a first step not the only step.
I mention emotional attachment twice because twice to logical and attempted factual comments I’ve gotten emotional comments back verging on attacking me personally. I don’t use iterm2 nor is it a piece of software that takes up any mindspace for me but attacking this aggressively anyone even mildly critical because you feel like you’re part of this minority group and you need to defend yourself because you feel constantly attacked is tribalism, not empathy and appreciation.
I mention emotional attachment twice because twice to logical and attempted factual comments I’ve gotten emotional comments back verging on attacking me personally. I don’t use iterm2 nor is it a piece of software that takes up any mindspace for me but attacking this aggressively anyone even mildly critical because you feel like you’re part of this minority group and you need to defend yourself because you feel constantly attacked is tribalism, not empathy and appreciation.
When you tell me that you're the lone voice of reason amid the emotional tribal backlash against you, despite people breaking down all the reasons they're calling you out step by step, I have nothing more to tell you. You might want to remember that your supposed "logic" won't stand in any FOSS community though. Or like, any community. I honestly hope that you can one day become a different person from the one who proudly proclaims that disregarding other people's work is proof of rationality.
Where did I ever claim I was the sole voice of reason? Plenty of people on here are having a rational discussion about how this happened and several people recommended tips such as commit hooks to prevent WIP work from getting committed and released. That would be an example of a lesson learned. Indeed, it's entirely possible that George has learned that lesson too. I was just literally describing the logical problem with the assumed logic of "mistake made = lesson learned", especially when there's no evidence outlining what the lesson learned was. Similarly plenty of comments in response to things I've said have been fairly well balanced.
As for the backlash, I just highlighted how 2 responses in particular seemed emotionally charged and border line attacked me for completely innocuous comments. The first was completely condescending and sarcastic while adding no additional value to the conversation on a completely unrelated comment thread where I suggested that maybe, just maybe, the terminal you choose isn't going to meaningfully improve your productivity. Your conversation has accused me of being in league with people threatening violence to the iTerm2 author and again adding nothing to the discussion about what lessons were actually learned and then attacking me and demeaning me in all sorts of ways and accusing me of saying things I simply have not. How would you describe that? A logical defense of someone I'm not attacking?
As for the backlash, I just highlighted how 2 responses in particular seemed emotionally charged and border line attacked me for completely innocuous comments. The first was completely condescending and sarcastic while adding no additional value to the conversation on a completely unrelated comment thread where I suggested that maybe, just maybe, the terminal you choose isn't going to meaningfully improve your productivity. Your conversation has accused me of being in league with people threatening violence to the iTerm2 author and again adding nothing to the discussion about what lessons were actually learned and then attacking me and demeaning me in all sorts of ways and accusing me of saying things I simply have not. How would you describe that? A logical defense of someone I'm not attacking?
Bringing up an arbitrary list of demands so that a FOSS dev can "prove" to you he has "learned"? That, is what, in your words, "adds nothing to the discussion."
Again you are claiming I said things I simply didn’t. Where did I come up with a list of arbitrary demands for him to prove he learned something?
All I said is that he simply didn’t say what he learned and provided examples of what it could look like. Again, I was very specifically responding to the claim at the beginning of the thread that a mistake made is a lesson learned isn’t actually true just because a mistake is made. It’s a very basic logical fallacy made by OP. And I point out how while he says he learned something he doesn’t actually clarify what the lesson is and what steps he’s taking to prevent said mistakes in the future. You may disagree but I feel like that adds something to the discussion.
I’m pretty done talking with you since it’s clear that you will continue conversing in bad faith and ascribing to me things I simply didn’t say.
All I said is that he simply didn’t say what he learned and provided examples of what it could look like. Again, I was very specifically responding to the claim at the beginning of the thread that a mistake made is a lesson learned isn’t actually true just because a mistake is made. It’s a very basic logical fallacy made by OP. And I point out how while he says he learned something he doesn’t actually clarify what the lesson is and what steps he’s taking to prevent said mistakes in the future. You may disagree but I feel like that adds something to the discussion.
I’m pretty done talking with you since it’s clear that you will continue conversing in bad faith and ascribing to me things I simply didn’t say.
They didn't assert that the author hasn't learned anything. They said that in the absence of information that they have, what they have and what they will do to prevent such issues in the future, you can assume they will make similar mistakes. Which may be more of a "better safe than sorry" strategy than you think is warranted, but that I don't perceive as an attack on the author.
Yes, you are right. Sometimes, reactions cause chain overreactions. We have different intensities of the situation. I checked the iTerm2 author's notes and compared them with my setup and I thought ok. It looks like I'm safe. And I moved on. But when I read your previous comment. I am now unsure because I need to know when and what changes led to this issue in the first place.
The iTerm team is just an army of one. There may be a formal analysis of the security soon.
The iTerm team is just an army of one. There may be a formal analysis of the security soon.
The root cause as I understand from other comments in this thread is a double whammy of the feature existing itself and that they managed to create a release with a WIP commit that enabled the feature. The resolved the issue by ripping out the feature. However, the latter issue remains unaddressed and to me is equally if not more concerning - there should be good practices in place to ensure that feature flags aren't even being controlled via code edits and instead there's .gitignor'ed config files that are read in a developer build for turning those features on. Additionally, git commit hooks that scan for WIP comments & prevent pushing them and sprinkling WIP comments around temporary changes might also be good defense in depth measures.
The terminal is the last bastion of the "good old times" for many people. that's why a terminal aiming at modernizing the experience is so triggering
iTerm2 doesn't interfere with people wanting the same old experience and you don't even have to use it either. Being "triggered" by a free and open source passion project that has helped countless number of developers around the world is beyond absurd. "Ungrateful" doesn't even begin to describe it.
Don't get me wrong, I like it.
But there's a fake nostalgia around terminals lately (nvim, oh-my-zsh, etc) and it seems emotional
People have always been emotional about their choice of software, I guess. But people are treating George, who has shown nothing but good faith this past 15 years of iTerm2 development, like the product manager of Windows Recall. That's a whole new level of emotional response which I don't understand where it's even coming from.
I mean the patch notes for this issue literally do this, so they seem to be off to a good start.
No, all the patch notes say is “I learned from my mistake and ripped out all the logging code”.
That’s not actually a postmortem of a list of process changes. Nothing about how WIP changes made it through into a code release nor in how such mistakes will be prevented in the future. There’s a much richer discussion of options in this thread of things people do to prevent things like this. For example, reading environment variables from a file that’s gitignored so that you never accidentally commit something and you don’t need to mutate code to do a config change.
He may indeed have learned from his mistakes, but I’m pointing out the flaw of assuming every mistake was treated as a learning opportunity, especially when no real evidence exists to suggest that.
That’s not actually a postmortem of a list of process changes. Nothing about how WIP changes made it through into a code release nor in how such mistakes will be prevented in the future. There’s a much richer discussion of options in this thread of things people do to prevent things like this. For example, reading environment variables from a file that’s gitignored so that you never accidentally commit something and you don’t need to mutate code to do a config change.
He may indeed have learned from his mistakes, but I’m pointing out the flaw of assuming every mistake was treated as a learning opportunity, especially when no real evidence exists to suggest that.
[deleted]
There was another issue where iTerm2 added AI functionality and then after some backlash allowed the ability to turn it off. If the additional features (which is why you would use iTerm2 in the first place) start making more and more problems it is starting to make more sense to use terminal.app or alternatives.
This is incorrect.
iTerm2 never enabled any AI features by default (it always required an OpenAPI key, which the user had to provide). The backlash was for including an AI related feature in the default build at all.
Following the backlash, I think they made it an optional plugin.
iTerm2 never enabled any AI features by default (it always required an OpenAPI key, which the user had to provide). The backlash was for including an AI related feature in the default build at all.
Following the backlash, I think they made it an optional plugin.
It should never have been anything other than an optional plugin but this doesn’t seem too harmful.
Wow -- as already posted, this is absolutely false. This is not at all what happened, the iterm2 folks are way more sensitive to their users' feelings than that.
You're right, but, as a user reading those release note for the first time, that's how it seemed. AI is being added? TO MY TERMINAL? Yes once I read it I understood it wasn't quite that bad, but the initial "Are you f*king kidding me?" feeling never left. AI. Next to my terminal. Please.
Looking at the replies here, I am not even sure how to react, it seems this community overall is going into a sad direction that just blames instead of trying to think of solutions.
Most of them are just entitled and aggressive for absolutely no reason.
It's perfectly fine to want to switch, or try something else, but to think other projects couldn't have issues is just naive to say it gently.
Most of them are just entitled and aggressive for absolutely no reason.
It's perfectly fine to want to switch, or try something else, but to think other projects couldn't have issues is just naive to say it gently.
I think that goes for society as a whole. We should all be more emphatic and considerate. Especially around things like this - it's not the end of the world. Software is difficult and shit happens all of the time, give the maintainers a break...
> We should all be more emphatic and considerate.
I'm sure it was just autocorrect being a nuisance, but you probably mean empathic.
I'm sure it was just autocorrect being a nuisance, but you probably mean empathic.
I agree that this isn't really something I'd switch over on its own, but what entitlement are you talking about? How is discussing not using an app or switching to something else... entitlement? I reread the whole thread and I couldn't find anything that felt like entitlement tbh...
Firstly, iterm2 is open source software (free as in beer and as in speech) and comes with no warranties.
Secondly, solo developer of iterm has excellent reputation from my point of view. History of his work on this project is something to strive for any developer and seems that always acts in (very) good faith while releasing software and replying to issues in threads.
https://news.ycombinator.com/item?id=42582206 - entitled for what features should exist or not in open source software. Also that feature was opt-in as far as I am aware. (EDIT: this user is also new and commented only on this post, with karma in the negative)
https://news.ycombinator.com/item?id=42581350 - entitled to how solo FOSS developer should act and write a critical update release response, with hints that said developer may not act in good faith.
https://news.ycombinator.com/item?id=42579595 - again entitled to what (or how many) features FOSS application should or shouldn’t have. Ironically also complains with entitled attitude that another FOSS software doesn’t have enough feature development.
There’s more, but obviously it’s subjective to reader’s interpretation. There were couple comments with attitude - that the developer shouldn’t be allowed to touch software ever again, but either I have missed them or they have deleted their comments.
Secondly, solo developer of iterm has excellent reputation from my point of view. History of his work on this project is something to strive for any developer and seems that always acts in (very) good faith while releasing software and replying to issues in threads.
https://news.ycombinator.com/item?id=42582206 - entitled for what features should exist or not in open source software. Also that feature was opt-in as far as I am aware. (EDIT: this user is also new and commented only on this post, with karma in the negative)
https://news.ycombinator.com/item?id=42581350 - entitled to how solo FOSS developer should act and write a critical update release response, with hints that said developer may not act in good faith.
https://news.ycombinator.com/item?id=42579595 - again entitled to what (or how many) features FOSS application should or shouldn’t have. Ironically also complains with entitled attitude that another FOSS software doesn’t have enough feature development.
There’s more, but obviously it’s subjective to reader’s interpretation. There were couple comments with attitude - that the developer shouldn’t be allowed to touch software ever again, but either I have missed them or they have deleted their comments.
> There were couple comments with attitude - that the developer shouldn’t be allowed to touch software ever again, but either I have missed them or they have deleted their comments.
It was too offensive and got flagged. Worse, the commenter doubled down instead of taking it back, I'm afraid.
https://news.ycombinator.com/item?id=42581359
It was too offensive and got flagged. Worse, the commenter doubled down instead of taking it back, I'm afraid.
https://news.ycombinator.com/item?id=42581359
I think it is fair to realise that the risks that come with using a third party terminal emulator do not outweight the pros of having some of its features for your usecase. But a lot of comments here are outright aggressive for no real reason.
Nailed it - entitled captures it accurately.
I've been on HN since 2011 and it has never been this hostile, unhelpful and flat out arrogant.
I've been on HN since 2011 and it has never been this hostile, unhelpful and flat out arrogant.
[deleted]
The developer of iTerm2 has a thankless job to be sure, but the reality is that when you build this kind of software you have a certain responsibility to be thoughtful and cautious and not indirectly cause harm to others. Security vulnerabilities like this can cause actual harm, so it's understandable that people see someone fail to live up to the responsibility and they get mad.
There aren't easy solutions to having responsibility. All you can do is live up to it, which sometimes means you need to apply rigor and processes that make hacking less fun, or that you need to make compromises you don't like.
"to think other projects couldn't have issues is just naive" is the wrong way to look at it. You should evaluate the processes that lead to the binary (or source tarball) that you're running on your machine. Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally? Do they run automated test suites before shipping?
There aren't easy solutions to having responsibility. All you can do is live up to it, which sometimes means you need to apply rigor and processes that make hacking less fun, or that you need to make compromises you don't like.
"to think other projects couldn't have issues is just naive" is the wrong way to look at it. You should evaluate the processes that lead to the binary (or source tarball) that you're running on your machine. Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally? Do they run automated test suites before shipping?
I can tell you that the commercial software that you use is unlikely to be living up to the unachievable standards that are being demanded in this thread.
In this case, the person is a solo developer, so who exactly should be reviewing the PRs?
I trust this developer because they have a long history of delivering quality software, with quick turnaround on bugs in general, and even faster on security related bugs like this one.
His "responsibility" is to maintain the trust that he will develop to the best of his ability and will react quickly to issues.
The so-called "rigor and processes" in current SW engineering are nonsense and busy work. Not once in my 40 years of SW development has a code review revealed a major bug that wasn't some sort of developer brain fart.
Maybe the actual security issue here is that a) /tmp is world read/writeable on many Unix/Linux VMs/machines, and b) you should lock down your SSH connections so that they don't have access to it.
Stop blaming the other person's software and look at your own security "rigor and processes".
In this case, the person is a solo developer, so who exactly should be reviewing the PRs?
I trust this developer because they have a long history of delivering quality software, with quick turnaround on bugs in general, and even faster on security related bugs like this one.
His "responsibility" is to maintain the trust that he will develop to the best of his ability and will react quickly to issues.
The so-called "rigor and processes" in current SW engineering are nonsense and busy work. Not once in my 40 years of SW development has a code review revealed a major bug that wasn't some sort of developer brain fart.
Maybe the actual security issue here is that a) /tmp is world read/writeable on many Unix/Linux VMs/machines, and b) you should lock down your SSH connections so that they don't have access to it.
Stop blaming the other person's software and look at your own security "rigor and processes".
What part of my post said the solution is commercial software?
If I understand the security vulnerability correctly here, what happened is a well-meaning and skilled engineer accidentally checked in debugging code and shipped it in multiple releases. This shouldn't happen if people are reviewing your PRs and if you're being cautious about what you ship.
If nobody else is reviewing the iTerm2 code that means the developer isn't getting the support he needs from the community, which is a shame.
The general tone of your comment is confusing though since it seems you're suggesting the solution to iTerm2 shipping a major security vulnerability is to just assume every piece of software is broken, instead of come up with ways to develop and ship more secure software. Are you really comfortable with every part of the software stack you use - firmware, OS kernel, libc, userspace - meeting this non-standard and being full of holes? Do you want to spend hours every day chasing down the latest vulnerability report?
If your experience with code review is that it never catches anything, either you're the greatest programmer in human history who never makes mistakes, or the people doing your code reviews aren't trying. I participate in open source code reviews on a daily basis against multiple repositories and we catch bugs/oversights in each others' work all the time.
If I understand the security vulnerability correctly here, what happened is a well-meaning and skilled engineer accidentally checked in debugging code and shipped it in multiple releases. This shouldn't happen if people are reviewing your PRs and if you're being cautious about what you ship.
If nobody else is reviewing the iTerm2 code that means the developer isn't getting the support he needs from the community, which is a shame.
The general tone of your comment is confusing though since it seems you're suggesting the solution to iTerm2 shipping a major security vulnerability is to just assume every piece of software is broken, instead of come up with ways to develop and ship more secure software. Are you really comfortable with every part of the software stack you use - firmware, OS kernel, libc, userspace - meeting this non-standard and being full of holes? Do you want to spend hours every day chasing down the latest vulnerability report?
If your experience with code review is that it never catches anything, either you're the greatest programmer in human history who never makes mistakes, or the people doing your code reviews aren't trying. I participate in open source code reviews on a daily basis against multiple repositories and we catch bugs/oversights in each others' work all the time.
My experience in commercial development is that code reviews don't work because the incentives are misaligned. There's no incentive for someone to do a proper code review, because finding a bug isn't rewarded in any way by either the reviewer or the developer. Most of the "bugs" found are either things that a good linter will pick up (variable naming, etc) or are minor.
Code reviews of peer's code in an open source project is very different because the incentives are there to promote transparency and visibility and there is a negative incentive for delivering code that doesn't pass review (general reputation, removal of committal rights etc).
The solution to iTerm2 shipping a major (it wasn't) security vulnerability is that when it is discovered, a new release with a fix is quickly released, the effects of the defect are clearly described and the mechanism for rectification is made clear.
iTerm2 did that, clearly and transparently.
The solution for developing and shipping more secure software is to remove options for things like world readable temporary files. The operating system should remove the capability such that you have to specifically enable it, which requires a conscious decision to do so.
Apple's SIP has removed a large number of opportunities for bugs, more could be done to fully sandbox user processes.
Making it impossible for a certain class of bugs to occur is a much better approach than code review attempting to find the problem after development.
Code reviews of peer's code in an open source project is very different because the incentives are there to promote transparency and visibility and there is a negative incentive for delivering code that doesn't pass review (general reputation, removal of committal rights etc).
The solution to iTerm2 shipping a major (it wasn't) security vulnerability is that when it is discovered, a new release with a fix is quickly released, the effects of the defect are clearly described and the mechanism for rectification is made clear.
iTerm2 did that, clearly and transparently.
The solution for developing and shipping more secure software is to remove options for things like world readable temporary files. The operating system should remove the capability such that you have to specifically enable it, which requires a conscious decision to do so.
Apple's SIP has removed a large number of opportunities for bugs, more could be done to fully sandbox user processes.
Making it impossible for a certain class of bugs to occur is a much better approach than code review attempting to find the problem after development.
Brain fart or not, the consequences are the same and this particular issue where verbose is left enabled [0] would 100% have been questioned in a code review, even by the most junior developer on the team. Now you probably shouldn't have such a security gap easily enabled by verbose flag in the first place but that's a parallel issue.
The author of his own hobby project is of course free to do whatever he wants without review and nobody can blame him for it. But anyone claiming code review doesn't find bugs has obviously never used them in a functional setting or only worked in small teams with only 10x developers. I estimate we find at least 1 bug per day in our code review process, even after tests and lint. On top of that there is also benefits by knowledge sharing of what's being changed and general improvement suggestions.
[0] https://news.ycombinator.com/item?id=42579607
The author of his own hobby project is of course free to do whatever he wants without review and nobody can blame him for it. But anyone claiming code review doesn't find bugs has obviously never used them in a functional setting or only worked in small teams with only 10x developers. I estimate we find at least 1 bug per day in our code review process, even after tests and lint. On top of that there is also benefits by knowledge sharing of what's being changed and general improvement suggestions.
[0] https://news.ycombinator.com/item?id=42579607
I didn't say that code reviews don't find bugs.
I said that they don't find major bugs. A code review wouldn't find a bug where the configuration at build time was incorrect for the build for production as it was in this case.
Testing finds the major bugs, not code reviews. If you are finding at least 1 bug per day, then there's something wrong with your development process, not your code reviews.
Oh and that's over 40 years as a developer and engineering manager in charge of delivering quality software with teams of ~10-20 for systems with 4 nines up time requirements and 24/7 operations.
I said that they don't find major bugs. A code review wouldn't find a bug where the configuration at build time was incorrect for the build for production as it was in this case.
Testing finds the major bugs, not code reviews. If you are finding at least 1 bug per day, then there's something wrong with your development process, not your code reviews.
Oh and that's over 40 years as a developer and engineering manager in charge of delivering quality software with teams of ~10-20 for systems with 4 nines up time requirements and 24/7 operations.
> Testing finds the major bugs, not code reviews
This bug was undeniably major and i highly doubt a standard test would have found this.
What would such a test look like, "test that no file in /tmp was touched"? That can only be done after you know such issue might exist, which is great to prevent regressions, but doesn't help to stop new unknown bugs. What else are you going to test for, no files in /foo were touched, no files in /bar and so on to infinity? "No files at all were touched", sure could be reasonable, but again keeps growing to an infinite set of "X must not happen", including other forms of IO like connections and API calls. Most security issues have this property, you can't test if a system is free of injection vulnerabilities, without exhausting every possible input combination or using advanced fuzzing techniques.
This bug was undeniably major and i highly doubt a standard test would have found this.
What would such a test look like, "test that no file in /tmp was touched"? That can only be done after you know such issue might exist, which is great to prevent regressions, but doesn't help to stop new unknown bugs. What else are you going to test for, no files in /foo were touched, no files in /bar and so on to infinity? "No files at all were touched", sure could be reasonable, but again keeps growing to an infinite set of "X must not happen", including other forms of IO like connections and API calls. Most security issues have this property, you can't test if a system is free of injection vulnerabilities, without exhausting every possible input combination or using advanced fuzzing techniques.
No, by making the bug impossible. Sandbox applications at the OS level so that they can't share /tmp. Apple has that for its OS, apps are jailed.
If we all lived in a fairy tale, sure, sandboxes are preferable. In this case to avoid the bug, every ssh server in the world would need a per-user tmpfs. Ideally, that would indeed be neat, short term it's not realistic. For the iterm2 case of a ssh client, an admin may also need to inspect the actual /tmp when debugging the server and then need to bypass the sandbox. A sandbox will never have the perfect granularity for every scenario. So we can't just throw our hands in the air and say "not my problem", alternative forms of verification are needed.
Besides, how do you test or review your sandbox and its configuration? Both are still needed.
Incidentally, k8s works a bit like this with no default shared tmpfs across containers. So such large scale production deployments are more protected against this type of issue. On the other hand, for debugging, as you would with ssh, it hardly has a concept of users at all, and lots of other ways to shoot yourself in the foot with :)
Besides, how do you test or review your sandbox and its configuration? Both are still needed.
Incidentally, k8s works a bit like this with no default shared tmpfs across containers. So such large scale production deployments are more protected against this type of issue. On the other hand, for debugging, as you would with ssh, it hardly has a concept of users at all, and lots of other ways to shoot yourself in the foot with :)
> when you build this kind of software you have a certain responsibility to be thoughtful and cautious and not indirectly cause harm to others
I think the only responsibility maintainers of an open source project have is to not intentionally cause harm, and even that might not be absolute (e.g. would it really be that wrong for maintainer(s) to remove a package/source code, if they so decide, like with the left-pad debacle).
> Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally?
There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
I think the only responsibility maintainers of an open source project have is to not intentionally cause harm, and even that might not be absolute (e.g. would it really be that wrong for maintainer(s) to remove a package/source code, if they so decide, like with the left-pad debacle).
> Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally?
There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
> I think the only responsibility maintainers of an open source project have is to not intentionally cause harm, and even that might not be absolute (e.g. would it really be that wrong for maintainer(s) to remove a package/source code, if they so decide, like with the left-pad debacle).
I understand this perspective as a developer but it feels kind of like a feel-good don't-worry-just-have-fun thing. Don't worry, just have fun is how we get big security breaches that cause measurable harm on real people.
It's fine to not worry and have fun if you're hacking on something that isn't a part of critical workflows or managing sensitive data, but a terminal is not that! The moment your app is asking a user to type in a password, you have a responsibility for what happens with what they type in! It's not only your responsibility but you simply have to be aware of the long term consequences of every action you take as a software developer, whether it's choosing not to bounds-check a memcpy call or choosing to add a dangerous verbose logging facility.
The bill for our decisions always comes due eventually and the question is who's paying the bill. In this case, the end users are paying for it.
> There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
I don't have a mac, but if I used iTerm2 I'd certainly be contributing to the author's patreon. It doesn't seem like many people are even doing that much, let alone reviewing commits. That makes me sad.
I understand this perspective as a developer but it feels kind of like a feel-good don't-worry-just-have-fun thing. Don't worry, just have fun is how we get big security breaches that cause measurable harm on real people.
It's fine to not worry and have fun if you're hacking on something that isn't a part of critical workflows or managing sensitive data, but a terminal is not that! The moment your app is asking a user to type in a password, you have a responsibility for what happens with what they type in! It's not only your responsibility but you simply have to be aware of the long term consequences of every action you take as a software developer, whether it's choosing not to bounds-check a memcpy call or choosing to add a dangerous verbose logging facility.
The bill for our decisions always comes due eventually and the question is who's paying the bill. In this case, the end users are paying for it.
> There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
I don't have a mac, but if I used iTerm2 I'd certainly be contributing to the author's patreon. It doesn't seem like many people are even doing that much, let alone reviewing commits. That makes me sad.
How are you the arbiter of what responsibilities the developer of one the the most incredible open source projects should have when you're happy collecting your Microsoft and Google paychecks literally spreading cancer on the internet in the form of AMP pages and straight-up closed-source trash?
I don't know what AMP has to do with anything - you can in fact search my post history to find me complaining about it, I bet - but if you don't like the reality that running code on other people's computers comes with responsibility you should probably move to another planet.
There's a spectrum of risk depending on the kind of software you're writing and the approach you take to writing it. One end of the spectrum is viruses, software designed to be malicious that the author absolutely should bear responsibility for the consequences of.
Another end is toy software created for fun shared with a few friends that doesn't do anything important. On that end of the spectrum you're all having a good time and as long as you don't do something stupid like delete system files with a buggy I/O routine, there's probably not much to worry about.
But surely you understand how iTerm2 is not toy software, right? It's essential infrastructure, and the security impact of this bug is large specifically because it's important software. Important software needs to be developed with caution because if you screw up people can lose their files or worse. This isn't a moral judgment or something I want to be true, it is true. If people don't like the responsibility that comes with developing essential infrastructure they shouldn't develop essential infrastructure, and as user/developer communities we should support the developers of essential infrastructure instead of pretending that rigor and quality are unimportant.
There's a spectrum of risk depending on the kind of software you're writing and the approach you take to writing it. One end of the spectrum is viruses, software designed to be malicious that the author absolutely should bear responsibility for the consequences of.
Another end is toy software created for fun shared with a few friends that doesn't do anything important. On that end of the spectrum you're all having a good time and as long as you don't do something stupid like delete system files with a buggy I/O routine, there's probably not much to worry about.
But surely you understand how iTerm2 is not toy software, right? It's essential infrastructure, and the security impact of this bug is large specifically because it's important software. Important software needs to be developed with caution because if you screw up people can lose their files or worse. This isn't a moral judgment or something I want to be true, it is true. If people don't like the responsibility that comes with developing essential infrastructure they shouldn't develop essential infrastructure, and as user/developer communities we should support the developers of essential infrastructure instead of pretending that rigor and quality are unimportant.
[deleted]
Glad I switched to Ghostty this week.
I thought we were all losing our mind over Ghostty anyway and iterm2 wasn't cool anymore because it's, apparently, slow?
I'm done with iTerm2.
This was a great terminal when it was basically Terminal.app + missing features but over the past years it has grown into the proveribal "Kitchen Sink" and now does SO MANY things that I just don't care about.
iTerm2 has become a huge app with many many knobs and levers and all kinds of functionality and integrations. I am not surprised at all that (security) bugs are found. More code, features, integrations means more potential for security issues.
I switched to Ghostty, yes which had a security issue last week!, but at least it is a pretty minimal app with so far no intent to meet iTerm2 in terms of functionality.
This was a great terminal when it was basically Terminal.app + missing features but over the past years it has grown into the proveribal "Kitchen Sink" and now does SO MANY things that I just don't care about.
iTerm2 has become a huge app with many many knobs and levers and all kinds of functionality and integrations. I am not surprised at all that (security) bugs are found. More code, features, integrations means more potential for security issues.
I switched to Ghostty, yes which had a security issue last week!, but at least it is a pretty minimal app with so far no intent to meet iTerm2 in terms of functionality.
> does SO MANY things that I just don't care about.
The integration of iTerm2 with Fish was so buggy that I needed to disable, then I lost some features like imgcat... These bugs persisted while they were introducing AI features that I really don't care (it's a terminal, why would we need AI???).
I think it's time for me to move on... I don't need too much, just something that works as good as Konsole does on Linux distros. The comments here (yours included) made me consider using Ghostty.
The integration of iTerm2 with Fish was so buggy that I needed to disable, then I lost some features like imgcat... These bugs persisted while they were introducing AI features that I really don't care (it's a terminal, why would we need AI???).
I think it's time for me to move on... I don't need too much, just something that works as good as Konsole does on Linux distros. The comments here (yours included) made me consider using Ghostty.
> These bugs persisted while they were introducing AI features that I really don't care (it's a terminal, why would we need AI???).
Many terminal programs, especially older ones, are known for having confusing or unintuitive interfaces, especially if you use them sparingly and you need to do something specific that can't immediately be gleaned from search results or from the man page.
I've personally found Claude to be tremendously helpful for these cases; I am now much more confident in my use of ffmpeg, as Claude can often zero-shot the invocation for my particular need, or give me the opportunity to follow up and narrow the details of the problem.
Given that, I'd happily welcome the iTerm2 integration, which I'm led to believe was optional, as I could readily specify the behaviour / action I want in natural language and have the AI produce the correct invocation without having to leave the terminal.
This could also be addressed through a CLI application to invoke a LLM (i.e. simonw's `llm`), but that's not as convenient as having the terminal itself insert the LLM's response for evaluation and execution.
Many terminal programs, especially older ones, are known for having confusing or unintuitive interfaces, especially if you use them sparingly and you need to do something specific that can't immediately be gleaned from search results or from the man page.
I've personally found Claude to be tremendously helpful for these cases; I am now much more confident in my use of ffmpeg, as Claude can often zero-shot the invocation for my particular need, or give me the opportunity to follow up and narrow the details of the problem.
Given that, I'd happily welcome the iTerm2 integration, which I'm led to believe was optional, as I could readily specify the behaviour / action I want in natural language and have the AI produce the correct invocation without having to leave the terminal.
This could also be addressed through a CLI application to invoke a LLM (i.e. simonw's `llm`), but that's not as convenient as having the terminal itself insert the LLM's response for evaluation and execution.
> Many terminal programs, especially older ones, are known for having confusing or unintuitive interfaces, especially if you use them sparingly and you need to do something specific that can't immediately be gleaned from search results or from the man page.
When there is such a rich database of manual pages and q/a about these tools, I tend to blame the user rather than the tool when I hear it called "too complex".
Additionally, if you don't understand what the command is doing why are you about to execute it in your terminal?
When there is such a rich database of manual pages and q/a about these tools, I tend to blame the user rather than the tool when I hear it called "too complex".
Additionally, if you don't understand what the command is doing why are you about to execute it in your terminal?
> When there is such a rich database of manual pages and q/a about these tools, I tend to blame the user rather than the tool when I hear it called "too complex".
Strong disagree. The example they gave about ffmpeg is a great example. Let's say I'm a casual ffmpeg user that wants to wrangle some videos one way or another.
I don't have the time to dig through ffmpeg's manual with tons of different options and terms that I don't understand just to figure out, as a trivial example, how to convert an mp4 to an mp3 while maintaining the best quality possible. I have 0 interest in learning about media formats, codecs, etc. I just want the result. This is not unreasonable.
With ChatGPT/Claude/etc, this is an even more trivial task. Nothing wrong with that. I'm willing to take the (minimal) risk of running an ffmpeg command while taking a common sense glance at it. It won't destroy my existing file. Or I'll run it on a copy if I'm being paranoid. I'm not dumb enough to destroy my machine or get some malware by running an unfamiliar ffmpeg command I copy pasted.
My #1 usage for LLMs is bash/zsh commands. Shell syntax is miserable to say the least.
Strong disagree. The example they gave about ffmpeg is a great example. Let's say I'm a casual ffmpeg user that wants to wrangle some videos one way or another.
I don't have the time to dig through ffmpeg's manual with tons of different options and terms that I don't understand just to figure out, as a trivial example, how to convert an mp4 to an mp3 while maintaining the best quality possible. I have 0 interest in learning about media formats, codecs, etc. I just want the result. This is not unreasonable.
With ChatGPT/Claude/etc, this is an even more trivial task. Nothing wrong with that. I'm willing to take the (minimal) risk of running an ffmpeg command while taking a common sense glance at it. It won't destroy my existing file. Or I'll run it on a copy if I'm being paranoid. I'm not dumb enough to destroy my machine or get some malware by running an unfamiliar ffmpeg command I copy pasted.
My #1 usage for LLMs is bash/zsh commands. Shell syntax is miserable to say the least.
> When there is such a rich database of manual pages and q/a about these tools, I tend to blame the user rather than the tool when I hear it called "too complex".
Extensive documentation doesn't mean the interface is good. `tar` is probably one of the most documented commands of all time, but that hasn't stopped it from being the subject of an XKCD [0].
> Additionally, if you don't understand what the command is doing why are you about to execute it in your terminal?
I can look up what the LLM's generated, or assess it from looking at it. (Comprehension is not the same as production.)
In general, I can work without it, but I'm a lot happier with it: when I need to encode a video to x264 with an acceptable bitrate while burning in the embedded subtitles, downmixing to two audio channels, and boosting audio by 20%, I can just ask that, instead of looking at 7 SO/SE/man/wiki/random blog post tabs and synthesizing it myself. I can do that. It's not a good use of my time.
[0]: https://xkcd.com/1168/
Extensive documentation doesn't mean the interface is good. `tar` is probably one of the most documented commands of all time, but that hasn't stopped it from being the subject of an XKCD [0].
> Additionally, if you don't understand what the command is doing why are you about to execute it in your terminal?
I can look up what the LLM's generated, or assess it from looking at it. (Comprehension is not the same as production.)
In general, I can work without it, but I'm a lot happier with it: when I need to encode a video to x264 with an acceptable bitrate while burning in the embedded subtitles, downmixing to two audio channels, and boosting audio by 20%, I can just ask that, instead of looking at 7 SO/SE/man/wiki/random blog post tabs and synthesizing it myself. I can do that. It's not a good use of my time.
[0]: https://xkcd.com/1168/
tried out ghostty but its still missing some key features like cmd+F for searching. sadly sticking with iterm for now
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a... https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...