Just because you can't do something ethically doesn't mean you should do it unethically, it means you shouldn't do it. Nobody here seems to have learned anything.
They could have done it ethically. Say that the study will run for undetermined amount of time. Even if they can be vigilant, they can't be vigilant for long time.
They could have gotten buy in from a few senior members of the linux community/foundation and verified that they weren't involved in the patches for the paper. It would introduce some risk of bias but could ensure that the work was ethical.
> before running this study; we did that because we knew we could not
ask the maintainers of Linux for permission, or they
would be on the lookout for the hypocrite patches.
Hated as they may be, I believe they’ve changed the way we think about code review. The fact is that there are malicious actors out there, likely far more advanced, and in positions of far greater trust. Modern devops has nearly eliminated human code review in favor of functional unit tests, and security is maybe something considered at release testing. And although the Linux kernel devs may be able to catch these things, there are countless other projects now realizing that they would not have. I don’t think humans can do this. We need to develop better automated tools to test for security in continuous integration of individual commits. For instance, it is normal for CI tools to include functional unit tests for interface implementations, but certainly less so to fuzz every interface as well. I don’t think it’s sufficient to simply fuzz the user inputs. A baked-in exploit would never be discovered that way.
