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.
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.
> 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.
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.
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.
> 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.
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.
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.
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)
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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 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.
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.
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!
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.
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.
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.
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.
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).
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 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.
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.
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.
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].
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.
> 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.
Readit News
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
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.
Includes a GitHub CI action to prevent merging it in to master
It has caught so many of these mistakes for me…
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.
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.
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.
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.
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.
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.
If that's true I don't feel entitled to expect anything 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)
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.
what steps we can take is that it's now a lesson to make it more caution when we went into that path.
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.
Seems like a good first step.
Dead Comment
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.
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
- 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.)
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"
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.
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?
So the move there is to install Rectangle.app (https://rectangleapp.com/), the successor to Spectacle, and then choose your terminal independently.
https://textual.textualize.io/FAQ/#why-doesnt-textual-look-g...
[1] https://github.com/ghostty-org/ghostty
No other terminal implements it AFAIK.
So, what magic am I using without realizing it?
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 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.
Deleted Comment
But probably that's terrible advice for 99.8% of people out there, probably more like 99.998, or even more 9s.
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'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 still prefer the blurred transparency of Terminal over the too transparent Windows Terminal, but that’s a matter of taste.
Well suited replacement for iterm2 and terminal.app, imo
Deniable ("popular app") increase in attack surface?
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 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.
https://github.com/wez/wezterm/issues/4051
At least iTerm has been around for over a decade and loved by many hardcore power users.
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.
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.
Not to mention the exorbitant price for a lifetime license.
Deleted Comment
Dead Comment
Dead Comment
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
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.
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.