iTerm2 critical security release
iterm2.com
iterm2.com
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a... https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
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.
It's all it took. Just making a clear distinction between the two and communicating it with the team.
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.
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.
# TODO: set back to 0
This appears as a warning in my editor, and of course is greppable
Includes a GitHub CI action to prevent merging it in to master
It has caught so many of these mistakes for me…
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.
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.
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.
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))?
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.
It’s fine. Not mindblowing, not bad at all. Just fine.
what steps we can take is that it's now a lesson to make it more caution when we went into that path.
Seems like a good first step.
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.
https://textual.textualize.io/FAQ/#why-doesnt-textual-look-g...
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 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"
His "style" compounds on that by making him seem untrustworthy.
confirm-close-surface = false
macos-titlebar-style = tabs
theme = IR_BlackNo other terminal implements it AFAIK.
So, what magic am I using without realizing it?
i believe the session can even be shared with a normal tmux session.
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.
Deniable ("popular app") increase in attack surface?
But probably that's terrible advice for 99.8% of people out there, probably more like 99.998, or even more 9s.
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.
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.
Designed to help environments that haven't reached 2010 era of automation of Salt or Chef.
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".
Every feature to one person can be a crutch to the next. Adding Salt or Chef to anything also increases the attack surface.
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.
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).
Well suited replacement for iterm2 and terminal.app, imo
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
- 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 still prefer the blurred transparency of Terminal over the too transparent Windows Terminal, but that’s a matter of taste.
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.
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.
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 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.
At least iTerm has been around for over a decade and loved by many hardcore power users.
Location
This app may use your location even when it isn't open, ...
Not to mention the exorbitant price for a lifetime license.
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.
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 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.
- 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.
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.
[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.
I should also get around to switching to tmux, now that GNU Screen seems to be stagnant...
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".
What others am I missing?
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.)
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.
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.
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’ll give it another go at the weekend.
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.
I configured
bold-is-bright = true
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.
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.
> GNU Screen seems to be stagnant
Is it stagnant or mostly complete?
v4 2006: feature complete, survived 18 years of attacks
v5 2024: new auth functionality, survived 4 months of attacksNothing, 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
Long live Terminal.app
I don’t personally iTerm2 to be be either of those.
That's not a new thing...
I get old code smell, and why folks might want something architecturally different, whatever - but screen is functionally feature complete.
It also has every feature known to exist in this space.
I agree though that the world is moving in the way of tmux - I'll get around to switching occasionally.
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 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.
Why don't you just use the stable releases?
I used Terminal for many years, too, but switched to iTerm2 a little over a year ago as I wanted to learn neovim.
- split pane support - profile switching (I have my colors change for different environments I ssh into). - tmux integration
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
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.
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.
Curious about how this happens. What does "framer" mean, here?
https://gitlab.com/gnachman/iterm2/-/commit/014ba7ec40fc790f...
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 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.
Unapproved usage of the exploit?
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.
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.
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.
Just because I like open source, doesnt mean I need to do literally all the work.
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.
What's not fine is verbose logging being turned on by default, most likely by mistake
Tha macOS part uses the rust `objc2` crates which I find high quality and the codebase is a joy to read.
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.
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.
Just don't use iTerm2.
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.
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 :)
Thinking there are more people who switched out of Terminal diminishes how massive computing is.
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?
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.
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.
It’s interesting the emotional reaction you’re having to a rather banal observation.
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
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.
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.
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.
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.
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/
It’s certainly not perfect, but I do prefer it. But then, I enjoy yak shaving grin
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.
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.
Just because something else is faster doesn’t mean that iTerm is slow. It’s all relative.
If you are thinking about a change, console marketing would be a good place to start ;)
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.
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?
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.
People are allowed to have opinions. In the same spirit, others are allowed to call out inappropriate or toxic behavior.
Also,
> Hackernews hoi polloi coming out of the woodwork saying how ... he has mouths to feed
Do you not understand what people mean when they say iTerm2 is free and open source software developed in a single person's spare time, and people aren't owed any of it? You didn't pay your metaphorical mechanic. Such bold sense of entitlement.
What's even more unfortunate is your take on my previous comment:
> linking to critical Yelp reviews of your new mechanic
Let me be more clear. You'll find something to pick on in any FOSS software. When you bring it up, no FOSS community will tolerate the kind of attitude you put on full display here.
Last but not least,
> This emotional attachment to a piece of throwaway software here is frankly weird.
Piece of throwaway software? Do words have no meaning to you? This is 15 year's worth of work that you're belittling. That work consists not only of coding, but coordinating with users and other software projects. I've seen him many times in issue trackers of various other projects. He's giving away all of that work for free. Imagine having to deal with people like you on top of all that.
Seriously, give the poor dev a rest. It's absolutely uncalled for to throw in a non-sequitur about some bug from 7 years ago, making snide remarks about how that's a "design choice."
[1]: https://gitlab.com/gnachman/iterm2/-/issues/6068#note_409052...
[2]: https://gitlab.com/gnachman/iterm2/-/wikis/dnslookupissue
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 love my MBP M4 Pro, but its gaming performance doesn’t reflect well what it’s capable of.
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.
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.
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.
macOS users of Apple and NeXTSTEP culture linage don't care iTerm2 exists at all, only Linux and BSD refugees.
Most would only get it via MPW, and outside automating compiler workflows, hardly open the terminal.
People on classic Mac weren’t making web apps running on Linux servers.
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.
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.
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.
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.
A random rockstar will come in and move the code forward 5 years never to be seen again.
lol. lmao. When I was at Apple it was one guy to like 4 apps
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.
*cries in Xcode
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!
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.
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...
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.
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.
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.
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?
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.
The iTerm team is just an army of one. There may be a formal analysis of the security soon.
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 same class of issue can occur for any other project
DON'T WRITE TO /tmp
> 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.
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'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.
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.
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).
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 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.
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.
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.
LastPass disagrees.
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'm sure it was just autocorrect being a nuisance, but you probably mean empathic.
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?
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".
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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.
It was too offensive and got flagged. Worse, the commenter doubled down instead of taking it back, I'm afraid.
I've been on HN since 2011 and it has never been this hostile, unhelpful and flat out arrogant.
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.
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.
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.
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?
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.
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.