To: sp21-pcchairs@ieee-security.org, a.oprea@northeastern.edu, thorsten.holz@rub.de CC: rm@ins.jku.at, santiagotorres@purdue.edu, sarah@openprivacy.ca Subject: Ethics concerns about paper accepted for publication Dear IEEE S&P PC Chairs, We are a group of security professionals and academics who are reaching out with concerns about the ethics on a paper that was recently accepted to appear in IEEE S&P 2021. The paper in question is "Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits", and we were made aware of its acceptance through Twitter by one of the authors (likely the PI of the research group). To our dismay, it appears that the research did perform experiments with human subjects (open source developers), yet there is no indication that the experiment itself went through any type of IRB approval process[2]. To further complicate things, it appears that the experiment has dire consequences: introducing exploitable code in perhaps the most fundamental part of computing infrastructure today -- the Linux kernel. We are reaching out because we believe this is a delicate circumstance that may taint the relationship between academics and open source professionals everywhere. If researchers are not trusted within open source circles, research relationships, experiments and dissemination of intellectual work will be affected. This is not to mention that open source has historically been a common medium for academic research to have broader impact. At this point, it is hard to evaluate the impact of this work in the security of the Linux kernel. We have reached the authors through different media (Twitter, Direct Messages and Email), they claim that no user was affected. However, our interaction with members of the Core Team of the Linux Kernel suggests they were never aware of this work, and find it difficult to assess the impact of the patches submitted --- this is particularly aggravating considering these individuals are already overburdened[1]. In fact, identifying the vulnerable commits may not be enough, as pipelines like "Automated Backports" may apply vulnerable commits to other release channels but may *not* include the commits fixing these[3][4]. This is made increasingly hard by the fact that none of the commits indicate publicly if they are malicious or not. We hope that the Program Committee of IEEE S&P reconsiders their decision to accept this paper at once. Signed, Morten Linderud, Security Engineer and Arch Linux security team. Santiago Torres-Arias, Assistant Professor of Electrical and Computer Engineering, Purdue University. Sarah Jamie Lewis, Executive Director, Open Privacy Research Society René Mayrhofer, Head of Institute of Networks and Security, Johannes Kepler University [1]: Greg Kroah-Hartman has repeatedly mentioned the problem of keeping up with patch review. https://www.theregister.com/2020/10/26/linux_kernel_intel/ [2]: Question: "Did this go through an ethics review board?" Answer: "The paper will be available soon. No, we did not. This is a regular bug-patching process, as researchers in this area have been doing. The only difference is we split the patching of a bug into two steps. Details are in the paper. I can share a copy with you in email." https://web.archive.org/web/20201122173246/https://twitter.com/kengiter/status/1330561671144878080 [3]: Automated backports: https://backports.wiki.kernel.org/index.php/Main_Page [4]: https://grsecurity.net/teardown_of_a_failed_linux_lts_spectre_fix --- [pade send ref HackMD] [https://hackmd.io](https://) ``` ``` ``` ```