Looking at the replies here, I am not even sure how to react, it seems this community overall is going into a sad direction that just blames instead of trying to think of solutions.
Most of them are just entitled and aggressive for absolutely no reason.
It's perfectly fine to want to switch, or try something else, but to think other projects couldn't have issues is just naive to say it gently.
I think that goes for society as a whole. We should all be more emphatic and considerate. Especially around things like this - it's not the end of the world. Software is difficult and shit happens all of the time, give the maintainers a break...
I agree that this isn't really something I'd switch over on its own, but what entitlement are you talking about? How is discussing not using an app or switching to something else... entitlement? I reread the whole thread and I couldn't find anything that felt like entitlement tbh...
Firstly, iterm2 is open source software (free as in beer and as in speech) and comes with no warranties.
Secondly, solo developer of iterm has excellent reputation from my point of view. History of his work on this project is something to strive for any developer and seems that always acts in (very) good faith while releasing software and replying to issues in threads.
https://news.ycombinator.com/item?id=42582206 - entitled for what features should exist or not in open source software. Also that feature was opt-in as far as I am aware. (EDIT: this user is also new and commented only on this post, with karma in the negative)
https://news.ycombinator.com/item?id=42581350 - entitled to how solo FOSS developer should act and write a critical update release response, with hints that said developer may not act in good faith.
https://news.ycombinator.com/item?id=42579595 - again entitled to what (or how many) features FOSS application should or shouldn’t have. Ironically also complains with entitled attitude that another FOSS software doesn’t have enough feature development.
There’s more, but obviously it’s subjective to reader’s interpretation. There were couple comments with attitude - that the developer shouldn’t be allowed to touch software ever again, but either I have missed them or they have deleted their comments.
> 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 think it is fair to realise that the risks that come with using a third party terminal emulator do not outweight the pros of having some of its features for your usecase. But a lot of comments here are outright aggressive for no real reason.
The developer of iTerm2 has a thankless job to be sure, but the reality is that when you build this kind of software you have a certain responsibility to be thoughtful and cautious and not indirectly cause harm to others. Security vulnerabilities like this can cause actual harm, so it's understandable that people see someone fail to live up to the responsibility and they get mad.
There aren't easy solutions to having responsibility. All you can do is live up to it, which sometimes means you need to apply rigor and processes that make hacking less fun, or that you need to make compromises you don't like.
"to think other projects couldn't have issues is just naive" is the wrong way to look at it. You should evaluate the processes that lead to the binary (or source tarball) that you're running on your machine. Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally? Do they run automated test suites before shipping?
I can tell you that the commercial software that you use is unlikely to be living up to the unachievable standards that are being demanded in this thread.
In this case, the person is a solo developer, so who exactly should be reviewing the PRs?
I trust this developer because they have a long history of delivering quality software, with quick turnaround on bugs in general, and even faster on security related bugs like this one.
His "responsibility" is to maintain the trust that he will develop to the best of his ability and will react quickly to issues.
The so-called "rigor and processes" in current SW engineering are nonsense and busy work. Not once in my 40 years of SW development has a code review revealed a major bug that wasn't some sort of developer brain fart.
Maybe the actual security issue here is that a) /tmp is world read/writeable on many Unix/Linux VMs/machines, and b) you should lock down your SSH connections so that they don't have access to it.
Stop blaming the other person's software and look at your own security "rigor and processes".
What part of my post said the solution is commercial software?
If I understand the security vulnerability correctly here, what happened is a well-meaning and skilled engineer accidentally checked in debugging code and shipped it in multiple releases. This shouldn't happen if people are reviewing your PRs and if you're being cautious about what you ship.
If nobody else is reviewing the iTerm2 code that means the developer isn't getting the support he needs from the community, which is a shame.
The general tone of your comment is confusing though since it seems you're suggesting the solution to iTerm2 shipping a major security vulnerability is to just assume every piece of software is broken, instead of come up with ways to develop and ship more secure software. Are you really comfortable with every part of the software stack you use - firmware, OS kernel, libc, userspace - meeting this non-standard and being full of holes? Do you want to spend hours every day chasing down the latest vulnerability report?
If your experience with code review is that it never catches anything, either you're the greatest programmer in human history who never makes mistakes, or the people doing your code reviews aren't trying. I participate in open source code reviews on a daily basis against multiple repositories and we catch bugs/oversights in each others' work all the time.
My experience in commercial development is that code reviews don't work because the incentives are misaligned. There's no incentive for someone to do a proper code review, because finding a bug isn't rewarded in any way by either the reviewer or the developer. Most of the "bugs" found are either things that a good linter will pick up (variable naming, etc) or are minor.
Code reviews of peer's code in an open source project is very different because the incentives are there to promote transparency and visibility and there is a negative incentive for delivering code that doesn't pass review (general reputation, removal of committal rights etc).
The solution to iTerm2 shipping a major (it wasn't) security vulnerability is that when it is discovered, a new release with a fix is quickly released, the effects of the defect are clearly described and the mechanism for rectification is made clear.
iTerm2 did that, clearly and transparently.
The solution for developing and shipping more secure software is to remove options for things like world readable temporary files. The operating system should remove the capability such that you have to specifically enable it, which requires a conscious decision to do so.
Apple's SIP has removed a large number of opportunities for bugs, more could be done to fully sandbox user processes.
Making it impossible for a certain class of bugs to occur is a much better approach than code review attempting to find the problem after development.
Brain fart or not, the consequences are the same and this particular issue where verbose is left enabled [0] would 100% have been questioned in a code review, even by the most junior developer on the team. Now you probably shouldn't have such a security gap easily enabled by verbose flag in the first place but that's a parallel issue.
The author of his own hobby project is of course free to do whatever he wants without review and nobody can blame him for it. But anyone claiming code review doesn't find bugs has obviously never used them in a functional setting or only worked in small teams with only 10x developers. I estimate we find at least 1 bug per day in our code review process, even after tests and lint. On top of that there is also benefits by knowledge sharing of what's being changed and general improvement suggestions.
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.
If we all lived in a fairy tale, sure, sandboxes are preferable. In this case to avoid the bug, every ssh server in the world would need a per-user tmpfs. Ideally, that would indeed be neat, short term it's not realistic. For the iterm2 case of a ssh client, an admin may also need to inspect the actual /tmp when debugging the server and then need to bypass the sandbox. A sandbox will never have the perfect granularity for every scenario. So we can't just throw our hands in the air and say "not my problem", alternative forms of verification are needed.
Besides, how do you test or review your sandbox and its configuration? Both are still needed.
Incidentally, k8s works a bit like this with no default shared tmpfs across containers. So such large scale production deployments are more protected against this type of issue. On the other hand, for debugging, as you would with ssh, it hardly has a concept of users at all, and lots of other ways to shoot yourself in the foot with :)
> when you build this kind of software you have a certain responsibility to be thoughtful and cautious and not indirectly cause harm to others
I think the only responsibility maintainers of an open source project have is to not intentionally cause harm, and even that might not be absolute (e.g. would it really be that wrong for maintainer(s) to remove a package/source code, if they so decide, like with the left-pad debacle).
> Is every commit/PR being reviewed by someone other than the author? By multiple someones, ideally?
There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
> I think the only responsibility maintainers of an open source project have is to not intentionally cause harm, and even that might not be absolute (e.g. would it really be that wrong for maintainer(s) to remove a package/source code, if they so decide, like with the left-pad debacle).
I understand this perspective as a developer but it feels kind of like a feel-good don't-worry-just-have-fun thing. Don't worry, just have fun is how we get big security breaches that cause measurable harm on real people.
It's fine to not worry and have fun if you're hacking on something that isn't a part of critical workflows or managing sensitive data, but a terminal is not that! The moment your app is asking a user to type in a password, you have a responsibility for what happens with what they type in! It's not only your responsibility but you simply have to be aware of the long term consequences of every action you take as a software developer, whether it's choosing not to bounds-check a memcpy call or choosing to add a dangerous verbose logging facility.
The bill for our decisions always comes due eventually and the question is who's paying the bill. In this case, the end users are paying for it.
> There is a good chance that they would welcome additional maintainers, so you can try volunteering to do that.
I don't have a mac, but if I used iTerm2 I'd certainly be contributing to the author's patreon. It doesn't seem like many people are even doing that much, let alone reviewing commits. That makes me sad.
How are you the arbiter of what responsibilities the developer of one the the most incredible open source projects should have when you're happy collecting your Microsoft and Google paychecks literally spreading cancer on the internet in the form of AMP pages and straight-up closed-source trash?
I don't know what AMP has to do with anything - you can in fact search my post history to find me complaining about it, I bet - but if you don't like the reality that running code on other people's computers comes with responsibility you should probably move to another planet.
There's a spectrum of risk depending on the kind of software you're writing and the approach you take to writing it.
One end of the spectrum is viruses, software designed to be malicious that the author absolutely should bear responsibility for the consequences of.
Another end is toy software created for fun shared with a few friends that doesn't do anything important. On that end of the spectrum you're all having a good time and as long as you don't do something stupid like delete system files with a buggy I/O routine, there's probably not much to worry about.
But surely you understand how iTerm2 is not toy software, right? It's essential infrastructure, and the security impact of this bug is large specifically because it's important software. Important software needs to be developed with caution because if you screw up people can lose their files or worse. This isn't a moral judgment or something I want to be true, it is true. If people don't like the responsibility that comes with developing essential infrastructure they shouldn't develop essential infrastructure, and as user/developer communities we should support the developers of essential infrastructure instead of pretending that rigor and quality are unimportant.
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.