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.
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.