iTerm2: Please disable 'Perform DNS lookups to check if URLs are valid'

Yep. I'll put that out tonight.

3.1.1 is well tested. Everyone should upgrade. If you find regressions they'll be my highest priority.

This is a deeply unkind thing to say to someone who donates their free time to provide a public good. George apologized for his oversight and fixed the problem. Take him at his word and thank him.

Uhh, to be fair both reports were answered with appropriate concerns.

First made it sound like a very specific issue for that one user, and was given a way to disable it for him.

Second made it sound like an entire class of users would need it off, and an option switch was provided.

What do you think is more probable, that he intentionally left that hole open despite not directly benefitting from it, or simply that when he answered both original reports and provided an appropriate solution, he didn't fully think about the details and implications of what those issues meant?

Have you really never have a closed issue come back to you "went from bad to worse, abort!“ ?

and as a bonus fully patched and firewalled Win10 will happily pass DNS traffic thru DNScache daemon without any filtering

> VOID DNS responses that are blocked by a lot of networks

For ages I've been meaning to [figure out how to] report this to the iodine dev, but I actually set up iodine specifically to get a working network while I knew I'd briefly be visiting a hospital.

I discovered to my amusement that the (public!) hospital's IT infra is really, really good; I was trying to SSH directly on top of the iodine tunnel, and while the first few DNS requests associated with the connection setup would work and I'd get as far as getting a shell prompt, but everything would rapidly screech to a halt and jam up pretty much instantly after that; maybe I'd get a single character typed, then it would completely die. I figured I was looking at a remarkably well-put-together leaky-bucket implementation.

So I tried hacking usleep()s into likely-looking spots in the code, but that didn't seem to slow it down enough. iodine is a rather interesting program internally, and a quick overview while distractedly sitting in a waiting area wasn't entirely sufficient to figure out why I didn't seem to be slowing it down enough to be a problem.

Before this "production" test, I previously verified that iodine was working by running the client on an AWS box. IIRC, ping ran over the link for quite some time (less than an hour; many minutes) without a single hitch.

On another note, I found that iodine seemed utterly incapable of setting up a correctly-configured tunnel on my Arch (receiving/server) box; I always had to ifconfig the tunnel (I forget exactly) to make it work. Problem with that was, my ifconfig-ing only routed one specific IP address, iodine wanted to give connections their own discrete IPs, and old sessions that locked up would take a while to time out. So I made a gigantic hack-script that would repeatedly kill iodine over and over every 1.5 minutes if it didn't see an authenicated SSH login. Would be nice for everything to just work properly...

iTerm2 is great and George is absolutely responsive with any issue I've ever brought up. I am personally going to give him the benefit of the doubt here, I'm sure he'll fix things ASAP.

I don't think it's worth throwing the baby out with the bathwater. But this should at a minimum be an opt-in feature, and not opt-out. Better yet, it's probably not needed. I've almost never needed to interact with URLs in a clickable way via a terminal.

The author has fixed it, and clearly this has been an educational experience. Considering the professionalness of the rest of the app, I get the impression that the author is likely going to factor security considerations into the picture in a big way in the future.

It absolutely matters what the code intends to do. If it intends to do a DNS lookup, and does that, that's working properly, eepecially if it's doing an DNS lookup on what its regex says looks like a clickable URL. If it means to store an SSN in an encrypted DB and accidentally writes it to plaintext or sends it to twitter, that's a security flaw. If that same app is following the system standard method of doing DNS resolutions, what else should it do? Are you really suggesting that it should somehow encrypt a DNS lookup? Why should this app be held to a higher standard than every single other application that does DNS lookups? This is the absurdity I'm talking about.

I completely agree that one must take into account how that feature fits with your product, user expectations, and privacy, but none of that means a feature that works as intended is a security flaw.

As others have said, prefetching pages has been done for years. Checking to see if it's a valid domain isn't an unreasonable feature for iTerm's URL highlighting, and for those who would prefer it not, he's changed that behavior, but let's not pretend that it was some absurd use of data that no one could have reasonably predicted.

And lastly, let's also stop clutching our pearls about "transmitting data". IT did a DNS lookup, and while technically that means there was a transmission, it wasn't taking what people traditionally call user data and transmitting it to a foreign third party. It's perfectly reasonable to check a domain name against a DNS server. Maybe unwanted, yes, but not even remotely irrational or irresponsible.

Sorry, no idea personally. I don't use iTerm, I was just pointing out that hovering is a common user action (due to cut-n-paste). :)

I don't think this "feature" existed a couple of years ago.